If you work as a developer or in operations, you most likely have heard about DevOps. If not, I suggest reading “The Phoenix Project“. It is a great book that tells a story about a company working their way to a DevOps mindset.
While I love that book (I have read it 2x and listened to the audiobook at least 2x), one thing that always struck me as wrong is how they ignore the CISO and his security team. Granted, the CISO is acting like a jerk through most of the book, but ignoring security in your DevOps projects can lead to issues down the road.
In the book, one major issue they ran into was obfuscating some information in database that wasn’t thoroughly tested. The security team pushed (or rammed) this through without working with the Developers or Operations and it ended up bringing many systems down.
Another issue was when the Developers and Operations didn’t consult with Security and ended up with hard copies of credit card information, which is bad. Now, you could say that this wasn’t either the Developers or Operations fault, but I would say that case could be made that it was due to lack of good instructions in case of the system went down.
In any event, towards the end of the book, the CISO has an epiphany regarding how he should be doing his job (with some not so nice comments helping him along) and everyone started to work together. However, their idea of working together was keeping Security in the loop as to what they were doing.
There is a great book called “DevSecOps for Azure” that I read and one thing that stood out to me was a statement from the Dynatrace’s 2021 Chief Information Security Officer (CISO) report which stated that 63% of CISOs agree that shifting to modern delivery methods, like DevOps, has seriously impacted their ability to detect and manage software vulnerabilities and 60% say it is due to faster release cycles. So, by making things better for Developers and Operations, it seems to be making things harder for CISOs. There are a lot of other eye-opening statistics listed in the book as well.
DevSecOps brings together Developers, Security, and Operations, much like DevOps brought together Developers and Operations. Security is part of the team and instead of being kept in the loop, they are actively engaged in all the decision-making processes.
There are many places where Security can be brought in, but I would argue that the earlier the better. With that being said, here are the phases for the development project that Security should be involved in. Many of you will realize that these are all the phases of a development project! I will go into a bit more detail in each area further on.
- Planning
- Development (called pre-commit in the book)
- Source Control
- Build
- Testing and Release
- Monitoring in production.
Planning
There is a saying in the military, and many other places, “If you fail to plan, you plan to fail”. Of course, this is immediately followed by “No plan survives first contact with the enemy”. I mention both of these since you should be spending a large portion of your time planning your DevSecOps strategy.
It should also not be so set in stone that it cannot handle the needed changes. For example, there could be new vulnerabilities discovered that may require you to change how you handle certain aspects of Security in your DevSecOps strategy.
I would also recommend reading “The Unicorn Project“, written by the same author as the “The Phoenix Project”, which tells the same story as the “The Phoenix Project” but from more of a developer’s viewpoint. One reason I bring this up is because they have one board that approves the use of any new software, and it was risk-adverse they never approved anything.
While you want to do due diligence when looking at new software, you do not want to be so averse to change that you end up hurting your company in the long run.
Development
This will include items from which Integrated Development Environment (IDE) to use to which 3rd party libraries can be used. Other items to consider include will you use desktops, laptops, or virtual environments. Each has their own benefits. For instance, a desktop may be more powerful and could run needed Virtual Machines (VMs). Since it is stationary, it can stay behind firewalls or, in some cases, not be connected to a network at all. A laptop is portable making it easier for developers to go into a central location to work. And virtual environments can allow for the best of both worlds but can end up costing more in the long run.
Each environment also has their down sides. While there is an argument that the desktop machine can be the most secure since your Operations team has complete control of over it, it is stationary so it can make collaboration hard.
Since laptops are portable, they can easily be stolen (or left behind) and along with it, valuable source code. Now systems like Microsoft’s Bitlocker can encrypt a hard drive making it much harder to access the information, but not impossible.
Finally, virtual environments operation systems are under the control of which ever company is running them, so you have no control over when the OS is patched. You also need to access them via the internet (or some sort of direct connection to the hosting environment) so there a small, but not zero, chance that the information can be intercepted.
There are many other items to take into consideration when implementing your Development DevSecOps strategy. These were just an sampling.
Source Control
This is where you keep your code. Is it going to be stored locally or in the cloud somewhere? How are you setting up the repositories? Will everyone have access to everything, or will there be more controls? Who can create the repositories?
You also need to consider what steps will be taken before the source code is stored in your source control. Is the code being scanned for security issues? What about secrets like access keys?
Is the environment being audited (I hope the answer is yes). If it is, who is looking at the logs. One of the sayings we have in security along the lines of “Ingestion is not detection”. This means that just because you are auditing a system, you still need to look at the data to determine if anything unusual is happening. In Azure, you can send the logs to Microsoft Sentinel to detect issues.
Build
The main thing here is to make sure you build environment is secure. You want to make sure that someone has not gained the ability to add code to your build. Granted, it is easier to modify the source code directly, but that is the reason why some bad actors will try to break into the build environment since it has less attention on it.
Test and Release
Much like the Build environment, the Test environment needs to be secured. You would not want your test plan modified to skip testing for known security vulnerabilities that could be exploited.
You will also want to sign your output, especially if you are selling your code. You will want to make sure that the signing keys are kept security so that they cannot be used to sign malicious code.
You also need to make sure that the list of people who can deploy your code to production is small. That way it is easier to control access to help make sure that bad code does not get deployed.
Monitoring in production
Finally, you will still want to monitor the code once it is running in production. There are many ways to do this but one of the main ways is to audit access and monitor the logs.
There are many tools in Azure that can help with this.
Summary
This is a brief introduction to DevSecOps. In future posts, I will expand on each of the phases more.