According to GDPR Individuals have the right to access their personal data and supplementary information (see Articles 12 and 15 and Recital 63). Bitcoin meets this requirement as content is fully traceable and you can access your personal data and supplementary information anytime. The downside is that your data is not only for you accessible but for everyone. Monero, like bitcoin, is also fully traceable and you can access all your data at any time. But with Monero no one else than you can access your data.

The GDPR introduces a right for individuals to have their personal data erased (see articles 6, 9, 12, 17 and Recitals 65, 66). This is also called the right to “be forgotten”. Meeting this GDPR requirement is impossible when using Bitcoin. In fact, blockchain has not been designed to “be forgotten”, but rather to remember all transaction data since the genesis of a blockchain. In Monero also the right to be forgotten is extremely simplified. If you want to be forgotten, just “delete” all your keys.

The GDPR includes a right for individuals to have inaccurate personal data rectified, or completed if it is incomplete (see articles 5, 12, 16 and 19). Both cryptocurrencies do not meet this requirement, since both of them are subject to the second restrictive blockchain characteristic: immutability. This means that you cannot modify existing blocks in the chain as this will affect the control sum of all next blocks. While Monero strictly doesn’t meet this requirement, it doesn’t necessarily expose a risk since no one has visibility or can access your (wrong or incomplete) data.

GDPR requires you to consider and implement technical and organisational data protection measures and to integrate them into your processing activities during the design phase (article 25 GDPR). As for Bitcoin, it wasn’t developed with privacy in mind and any new application relying on Bitcoin will have to deal with this caveat. It’s worth noting that hundreds of other blockchain projects, whether launched via an ICO or not, have currently similar privacy problems. Monero on the other hand, was designed with privacy in mind. With the recent move to protect the blockchain against centralization and ASICS, they once again have shown and applied “privacy and security by design”.

 Since every Agile project is different, you could face one or all of these issues at once. Taking the above points into consideration, they may (and very often simply do) lead to a security cataclysm. The definition of the security cataclysm is very wide – from a security breach, through revoking the certification for the whole company (i.e., PCI-DSS), up to compromising a government agency. The belief that Agile and security cannot work together is so strong that it’s hard to find security experts who are willing to take the challenge and make it happen. Fortunately, there are a few things that we can do and may change that perception.

1. The first measure is to assign a security consultant to all agile squads. Let him/her attend all the stand ups, planning & grooming session, retrospection meetings, and be responsible for security. This should allow him or her to address any security or compliance issues before they are implemented, in other words this is a preventive activity. The maximum successful ratio is one consultant per four agile squads.

2. But that is not enough. Security also has to work closely with the scrum master and together enforce design works – addressed as product backlog item (PBI’s). This second measure will allow the project to perform security reviews based on the designs. These early reviews will lower the cost of any required penetration testing activities later prior the “go live” event. You will need to assign a security assessment subtask to each PBI to perform a security review. By doing this, you should minimize the mitigation costs, and address immediately security & compliance requirements. Another benefit from having a design is higher accuracy and better results from penetration testing. After 2 or 3 months, you should see the first results. Penetration testing should identify less vulnerabilities, less compliance failures to national or industry standards and the security posture should grow within your environment.

Let's say that with the above measures security can be agile. But you will say - it is expensive. Is it? Maybe. There is always a cost attached to improving security. But you can lower the costs by for example creating additional features i.e. a checkbox for penetration testing in JIRA. This will enable the team to coordinate release plan with penetration testing schedule, resulting in decreased number of engagements with a security company. You may encourage squad members to learn practices from the security consultant and introduce cross-quad security assessments. The cross-squad security assessment will also ensure the segregation of duties principle.

However, despite all propositions above, there is still one crucial thing missing. In this approach the security consultant doesn’t have a holistic view of the products and/or environment. This is key for security to be able to assess and provide valuable input to the project. Since that is not available in agile projects, the security consultant starts her/his engagement with a gap analysis against the desired security standard. The desired state and input from some architects is all (s)he needs. Reassessing the gap from time to time (i.e., every 6 months) is recommended here as projects requirements and the desired state change frequently in agile.

The proposed solutions above are not based on the laws of physics, but should bring security and the agile dogma closer to each other. If you have succeeded in bringing those two enemies together by other means please share with us and the world your revelations.