Build a culture for Continuous Delivery and Data Protection by Design and by Default.
In a series of articles, I will present a way of continuously delivering software while protecting the privacy of natural persons by design and by default.
It might happen to you that the schedule gets overrun and perhaps even that the project gets threatened by a shutdown. When that happens, the integrity of your culture will be tested. That’s when you will know whether you really have implemented measures to protect your organization’s culture for doing DevOps and data protection by design and by default.
As part of a social psychology experiment carried out by Stanford University in 1969 a team of researchers left two identical cars of the same model and same color in different streets. One was left in the Bronx of New York, the other was left in a wealthy neighborhood in California. Two identical cars abandoned in two neighborhoods with entirely different social-economic backgrounds. The car which was abandoned in the Bronx began to get stripped of tires, mirrors, and radios within a few hours. All useful contents were extracted and the remains destroyed. The car abandoned in California, however, remained intact. But the experiment didn’t end here. After the car abandoned in the Bronx had been stripped and demolished the researchers smashed the glass window on the car in California. What then happened was pretty much the same as in the Bronx: theft, violence, and vandalism reduced the car to the same state as the one in the slums.
Why would a broken glass lead to theft, violence, and vandalism? The reasoning behind is described as the “Broken window theory” which states that the state of the urban environment is affected by three factors.
- social norms and conformity
- the presence or lack of routine monitoring
- social signaling and signal crime
In an environment, with few or no people around, social norms and monitoring are not clearly known. Individuals will, therefore, look for signals within the environment to understand which social norms to follow and assess the risk of getting caught violating those norms; one of the signals is the area’s general appearance. When a broken glass window can corrupt the behavior of a healthy neighborhood, then it’s safe to assume that the same can happen for an organization as well, and it goes without saying that it’s required to fix them if you want a healthy culture.
During my university years, I experienced that first hand as I was taking a course at The Technical University in Berlin. A group of students was handing out flyers for a concert at the base of the stairs leading up to the second floor of the main building. One flight up, flyers were piling up on the floor as the students that were handed flyers decided to do the exact same thing as the students before them. I, therefore, decided to gather all the flyers and place them on the stair column without anyone noticing. And lo and behold 8 out of 10 changed behavior and placed the flyers in the exact same spot as I had put them. My actions had regulated the behavior of the students at the university by playing into their ability to look for social signals and follow social norms and conformity.
Relying on the individual’s ability to look for social signals, social norms and conformity may be sufficient for preventing littering on a university campus, but, while it plays a part, it won’t be enough to build a healthy organizational culture that naturally places security and privacy highest amongst its business concerns. The drive for profit, survival, and power is too strong for that to naturally happen. All it takes is a broken window for the norms and conformity to jump out.
Approaches to organizational change
In order to prevent such corruption of behavior and build a healthy culture, we need to be aware and address the main variables that play a part in bringing around organizational change and know how and when to use them.
In 1965, Harold J. Leavitt published a paper called “Applied Organizational Change in Industry; Structural, Technological and Humanistic Approaches” which later was included in the “Handbook of Organizations” edited by James G. March.
In his paper, Leavitt categorized 4 variables: structural, technological, human and task; where the first 3 of the variables can be seen as approaches seeking to affect the last variable, task. Leavitt sees these variables, in his paper, as highly interdependent so that when one of them changes, the others adjust accordingly.
He concludes in his paper, to paraphrase Leavitt, that there are many areas of organizational improvement «in which the criteria of creativity, flexibility, and capacity to deal with novel unprogrammed problems will remain critically important» e.g. in «research and development». In those areas, people approaches should be preferred. «In other, more highly programmed, task areas, in more constrained environments…» people approaches have much less to offer except for «…the psychological fulfillment of workers».
Technological approaches
So to conclude, it is perfectly ok to choose a technological approach to improve the organization. In many cases, it is actually preferred. Therefore we shouldn’t shy away from trying to find a tool that can make our life easier and more secure, but we need to be aware that there are things humans are much better at than machines e.g «research and development». It is, however, worth to mention that, in Leavitt’s model, technological approaches don’t necessarily need to imply a technical tool it could also be a process improvement tool like a Kanban board even though it’s drawn on the wall with post-its, paper, and tape. Technological approaches can play an important part in providing us with the right tools for building a healthy culture. A typical example could be a secure cloud storage solution like 1Password or Lastpass for storing passwords and usernames that also can facilitate secure sharing of credentials between members within and outside of the organization. For Continous delivery, it could be a solution like HashiCorp Vault which makes it easy to securely store application credentials so that continuous integration and deployment can be setup in a secure fashion without needing to hardcode application credentials in configuration files or in code repositories.
Structural approaches
Structural approaches, that Leavitt writes about, are mainly divided into 3 main groups. The classical approach that comes from military theorists were the core values are order, discipline, system, and acceptance of authority. Organizational change under the classical regime only happens as long as it follows line-of-command and happens in accordance with core values. The second set of approached seeks to modify the behavior of people through the structural property of the flow of work (flow-based). Lean Product Development’s use of Kanban boards and focus on waste reduction is a good example of these kinds of structural approached. The last is known as Scientific management made famous by William B. Taylor. The core beliefs amongst Scientific management theorists is that work best can be organized by having managers monitor and adjust the daily work routine of the employee through scientific measurements and monitoring and that technology is the ultimate solution to all efficiency challenges.
Many of the classical and scientific structural approaches have fallen out of favor due to their naivité when dealing with the human element, instead, flow-based structural approaches have become the defacto way of improving the organization within software development. This is of course not without its challenges. The flow-based approaches often stress the importance of having cross-functional teams, but the lack of competency within security, privacy, and operations can make organizational and cultural improvements difficult as the people with the necessary competency are high in demand across and outside the organization and therefore end up being bottlenecks and getting their availability reduced by management or simply by their sheer operational necessity. The result is often that knowledge sharing and team workshops get down-prioritized which have the effect of further eroding the organization’s culture and limiting the organization’s capability of addressing security, privacy, and continuous delivery issues.
People approaches
People approaches to organizational change have been steadily increasing in popularity. So much so that most agile management frameworks Like e.g. Scrum or Lean Product Development contain people approaches for continuous improvement. For Scrum, it’s the Retrospective and for Lean Product Development the use of Kaizen. The need for the human touch is, of course, understandable since no system or framework is perfect and therefore requires a human eye. And so it is for any CI/CD system, security architecture and privacy architecture as well. So much so that it is regarded as one of the basic principles within risk management and data protection by design and by default e.g. is one of the measures to allow the controller, according to article 25, to “create and improve security features” (recital 78). Recital 78 also mentions that a system should be developed “ with due regard to the state of the art”, meaning that you always should take into account that the environment in which the system operates is changing and that the system, therefore, needs to change with it. Thinking that the basic Sprint retrospective will address these challenges and hope that these things take care of itself is wishful thinking. Your security and privacy must be continuously monitored, reviewed and improved through your CI/CD pipelines to avoid that microservice development grinds to a halt.
Various supervisory authorities advice that a security and privacy review should be done before the system is released into production. It’s considered mandatory for high-risk processing and processing of special categories of personal data like health data. You should build your privacy and security review into your CI/CD pipelines and complete them on a regular Scrum/Kanban cadence in order to comply with privacy and security regulations so that you are able to continuously deliver software in an agile/lean way. In Norway, where I am currently working, the Norwegian Data Authority use several example checklists that you can use in order to cover all of the security and privacy requirements. I like to divide the security and privacy review into 3 distinct areas that can be divided and completed on a sprint by sprint basis. The three areas are:
- Security Sprint Review
- Privacy Sprint Review
- Tools and libraries Sprint Review
I will come back to these three reviews and why they are important in one of my next articles. If you're doing Kanban, you’ll probably even divide them into even smaller tasks that you’ll associate with Kanban lanes. You’ll probably end up with a really large Kanban board if you do so, but that’s the price you pay for getting better visibility into your value streams.
Building your compliance into your people processes is not only good for your continuous delivery strategy it’s also the best security-, privacy- and project risk management strategy you can hope for.
There is one important variable that Leavitt forgot about though. Customers…
Customer approaches
Customers have become a very important part of bringing about organizational change. So much so that a range of customer-centric approaches has sprung up something the Lean Startup Movement is a great example of. Many organizations have almost completely left the job of defining requirements up to their customers. Although that is a great idea in many cases, it might not always be that greatest for security and privacy requirements. e.g. In GDPR article 32, «Security of processing», it says that «the controller and the processor shall implement», which means that even if the controller actually is your customer, which rarely is the case, you should still make sure that you implement measures to protect the privacy and security of natural persons. It's not a good idea to leave security and privacy requirements entirely up to your customers, and they should probably not be responsible for improving your culture either. Frankly, that is your job.
Advice on the road
To round up, a couple of points coming from experience.
Building a culture for Continuous Delivery and Data protection by design and by default will require you, unless you are doing a really small project, to hire people that can work exclusively for making sure that you establish a culture for continuous delivery, privacy, and security. There is no other alternative. Hoping that a champion will appear that will implement all your legal vows is unrealistic. It is also preferable to have both a security architect and a security engineer on the team. The security architect will give advice to the client and the other architect while the security engineer will give technical guidance and implementation advice to all developers on the project. On a medium sized project involving both private and special categories of data, working with security and privacy concerns. require 3 fulltime positions or more depending on the complexity of the personal data, risk associated with the processing and the data flow.
Building alliances
When creating awareness for security, privacy, and DevOps, the scrum masters are your most important allies. Make sure you let them in on what you are doing. A good scrum master lives and breath for improving the culture and implementing changes in the organization. If a large part of the development effort is done offshore, it becomes even more important since the scrum masters, in many cases, will be your primary point of contact. If you are the security architect and do not have a security engineer on your team, then find a person among the lead developers with an interest in security and privacy that can take the role as the security engineer.
Project startup
It’s a very good idea to spend 3–4 sprints together at the beginning of the project to get time to go through the forming, storming and norming stages. It will make sure you get face time with your offshore time and can get a common understanding of your continuous delivery pipelines and security and privacy architecture. I have still not come across a video conferencing solution which is good for large groups so regular travels abroad will be required in any case. Make sure your security engineer and scrum master gets the possibility to meet face to face with your offshoring team a week or two for a couple of workshops when all the quality assurance and security processes are ready for implementation.
When you do the workshop. Try to get the team to participate in forming the processes themselves. There are a couple of ways you can do this. e.g. Once I had the whole team help me design the continuous delivery pipelines with all the quality gates on the whiteboard. Having them do the work ensured that they understood how they are meant to work and why they were there. The same can be done when designing the review processes as well. First, get the team to come up with a set of values and principles that is important for making sure your system is secure and uphold the basic principles of privacy by design and by default, then get the team to pitch in on how the team can make sure these principles and values are followed and how they can be integrated into your value stream. Value-stream mapping is one way of accomplishing this. When deciding values and principles it might be an idea to do a vote. Do not dwell too long on the suggestions, just make sure the discussions lead to a common understanding of the basic principles. Then do a vote where you select the most important principles. Design your processes with the selected principles and values as a base. Having the team vote makes sure that everyone accepts the choices that have been made and follows them.
To conclude
I started out this article to talk about the importance of fixing broken windows. I can not stop to stress how important that is. Your project will stand or fall depending on the number of broken windows you have. Show that you care, fix them, others will follow. Your most important tool will be your capacity for empathy and motivation for working with people, not against them. Build alliances, do not make compromises, take no prisoners and build a common understanding for security, privacy, and continuous delivery.
