This is the second part of this article, which I thought was necessary to write to get the industry talking.
I was initially prompted to write it because I have spent a lot of time over the last few months trying to find the ideal solution for businesses who are thinking about or are in the process of moving towards a DEV-OPS and Agile methodology.
The change, while essential to stay ahead of the game, is not an easy one to make or even explain, which is why it’s taken me so long to actually write this series of articles and open this potential can of worms.
In the first part of the article I took a closer look at the Agile Method and the challenges I had personally faced and what a perfect world of cybersecurity would look like - surely that’s a place we would all love to see :-)
Click here to read.
Agile and the security challenge
Now, here lies the first challenge, most of the time security architecture and security in general needs to take a holistic view.
As an example; take threat modelling, in order to do a proper threat model you would need a design of some sort of a conceptual idea of design.
With agile, you would never have that but at best some collective knowledge of the software.
What that means is that in order to have a security assessment (architectural or threat model) of a product you would need to do a retrospective one at a certain point in time.
That tells us that traditional architecture, threat modelling and other traditional techniques do not work in this modern approach to software development.
So, how do we make it all work together? Well, we could borrow some of the elements from our ideal world.
Let’s build in the automation, the principles and best practices. This enables the build by default of secure software.
Now the automation does not solve all the problems, but it definitely makes the review easier.
The retrospective approach with some time allocation to threat modelling could be a solution.
Two speeds of security architecture
There is no perfect one size fits all approach and an analysis of any team would enable the readiness for a DEV-OPS and Agile approach.
Moreover, the team will not naturally be ready for a DEV-OPS or Agile approach, which both require a cultural shift within any organisation.
Any change and cultural shift are affected by the following:
The time required for the change to take hold
Rejection of the change from the majority of the team and the adoption of it
Education and upskilling of the team with a mix of external resources to lead by example.
So going back to how security is affected by Agile methodology, well two speeds are required with a vision to move a team from one position (more waterfall and traditional architecture) to a more Agile one.
The change and shift take time, as well as a thorough evaluation of the team and the evolution in embedding security in design and development practices.
The key thing in the process is to have metrics and conditions very well defined to move a team from one speed to the other.
Measuring the conditions (or key security indicators) should be as automated as possible, this will prevent the human aspect and the bias that this implies.
Gates
Traditional
In a traditional model, the idea is to have a forum that approves a design (conceptual and high level) before it goes in the development and testing.
This governance and approval also then apply to testing and production.
This model is more traditional and would be stopping things going into production but that does not stop existing vulnerabilities in production.
Agile
Using the Agile Method, the change and release tempo is much faster with several releases per day, per application.
Now in this model, the governance is not as strong and would be undertaken between the project phase and production phase.
With this method there are two options:
Gates to block the transition of a change to production
No gate between the production but repeated security scanning in production
Now the first method still relies on a traditional command and control approach even if it is more of a ‘light touch’ than the other method.
The second is more challenging as it requires more trust in development teams and more automated technical security testing.
This is also more complex to build and would require the following prerequisites:
Design Phase:
Security principles
Security best practices
Revised policies with security principles
Solid standards with security principles
Threat modelling on security impacting changes or new feature
Is important to lay out the definition of security changes. Security impacting change is anything that drastically changes the function of the application itself.
Build Phase:
Perform an initial code scan
Strong development practices
Initial code scan
Library check
CVE checks against libraries
Build security artefacts into a repository
No deployment into the approved repository without a change request
Perform incremental scans of the code (for every change)
Perform retrospective static code analysis (if the change is significant)
Testing phase:
Create machines from approved images (golden images)
Deploy the built images from the approved repository (with a hash)
Verify that the application deployed in the test machines has the same hash as the one in the repository
Perform security testing (security use stories)
Perform infrastructure scanning
Perform dynamic code analysis
Cycle between build and test unless all the major vulnerabilities are solved
Production phase: In order to deploy a build in production, all the major to medium vulnerabilities should be solved (in line with the risk appetite)
Perform library check
Perform vulnerability check on the infrastructure
Deploy patches on the machines and patches
Perform rebuild of the image and re-deployment of the application (build) from the approved repository
Perform check to verify that the application is deployed from the approved repository hash check
Verify that the libraries are updated and do not have vulnerabilities
The above enables automation with just ‘light touch’ architecture.
The security architecture will then be able to focus on identifying issues in production and working on common patterns, which would enable a consistent security posture across the production estate.
Conclusion:
Depending on the effort and the risk appetite, it is possible to move to more automated security architecture and security practice.
If you’d like to discuss any of the issues I’ve mentioned in this article let’s chat or get in touch on Twitter, where you can find me @FrankSEC42.
Comentarios