With the change of DevOps afoot, traditional security is no longer an option. The mindset established by DevSecOps lends itself to a cooperative system whereby business operators are supplied with tools and processes that help with security decision making along with security staff that enable use and tuning for these tools.
Its mantra is to make everyone accountable for security with the objective of implementing security decisions and actions at the same scale and speed as development and operations decisions and actions.
Security in the Traditional Waterfall Development Model – by Charlie Belmer
Traditionally, security has worked with project teams during two phases of execution: technical requirements design and right before go-live.
After a team has gathered their business requirements and sorted out a target architecture, they may go to a security review, run through a threat modeling and data flow exercise, then take a stack of security requirements and put them into a design document. After they have a working program and users have signed off, the team comes back to security for sign off. At this point, security runs tools and penetration tests, and comes back with a stack of vulnerabilities.
Integrating & Automating Security for Agile Development
What is DevSecOps? (By Shannon Lietz)
- The purpose and intent of DevSecOps is to build on the mindset that “everyone is responsible for security” with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.
- While having a seat at the table has increased the effectiveness of security decisions, it’s since caused friction and a significant slow down in business outcomes because of a scarce supply of security skill sets to embed in the value creation process.
- Traditional security operates from the position that once a system has been designed, its security defects can then be determined by security staff and corrected by business operators before the system is released.
- As the value creation process speeds up to provide iterative value in order to closely map to customer demands, it is even more the case that a one-time tale end determination and testing of a complete system is actually destructive to the outcome.
- So with the change of DevOps afoot, traditional security is no longer an option. However, with the introduction of DevSecOps, it’s not necessary for risk reduction to be abandoned by either the business operators or security staff; instead, it should be embraced and made better by everyone within the organization and supported by those with the skills to contribute security value into the system.
- The mindset established by DevSecOps lends itself to a cooperative system whereby business operators are supplied with tools and processes that help with security decision making along with security staff that enable use and tuning for these tools.
- DevSecOps as a mindset and security transformation further lends itself towards cooperatither security changes. It doesn’t matter if you believe that security needs to be added into Development or Operations or some other business process, you are right! Security needs to be added to all business processes and a dedicated team needs to be created to establish an understanding of the business, tooling to discover flaws, continuous testing, and science to forecast how to make decisions as a business operator.
How Does DevSecOps Work?
The benefits of DevSecOps are simple: Enhanced automation throughout the software delivery pipeline eliminates mistakes and reduces attacks and downtime. Let’s take a look at a typical DevOps and DevSecOps workflow:
- A developer creates code within a version control management system.
- The changes are committed to the version control management system.
- An environment is then created, using an infrastructure-as-code tool, such as Chef. The application is deployed and security configurations are applied to the system.
- A test automation suite is then executed against the newly deployed application, including back-end, UI, integration, security tests and API.
- If the application passes these tests, it is deployed to a production environment.
- This new production environment is monitored continuously to identify any active security threats to the system.
Why Do We Need DevSecOps?
- The shift to agile cloud computing platforms, shared storage and data, and dynamic applications has brought huge benefits to organizations looking to thrive and grow through the use of advanced applications and services.
- While DevOps applications have stormed ahead in terms of speed, scale and functionality, they are often lacking in robust security and compliance.
- Hackers are always looking for the best ways to deploy malware and other exploits. Imagine if they were able to insert malware into an application during the build process, and that this malware was not discovered until the application had been distributed to thousands of customers.
- Making security an equal consideration alongside development and operations is a must for any organization involved in application development and distribution.
DevSecOps Best Practices (By Cyber Edu)
Organizations that want to unite IT operations, security teams and application developers need to integrate security into their DevOps pipelines. Here are just a few best practices that will make the DevSecOps process run smoothly:
- Automation is good – DevOps is all about speed of delivery, and this doesn’t need to be compromised just because you are adding security to the mix.
- Use DevSecOps for efficiency – You are only adding security to your workflows. By using tools that can scan code as you write it, you can find security issues early.
- Carry out threat modeling – Threat modeling exercises can help you to discover the vulnerabilities of your assets and plug any gaps in security controls. Forcepoint’s Dynamic Data Protection can help you to identify the riskiest events occurring across your infrastructure and to build the necessary protection into your DevSecOps workflows.
How to integrate security in agile projects – the first, effective step (By Charlie Belmer)
Security in Sprint Planning
When sprint planning, I ask teams to do a few things:
- Include security stories in the backlog, and prioritize them alongside business features. These may come about as a result of threat modeling or outputs from security audits / pentests / scanners.
- For each story selected for the current sprint, review a secure development checklist. Essentially this is a repository of guidelines on preventing common issues tied to functionality – using parameterized queries for DB interactions, filtering dynamic data before displaying on a web template, etc.
- Determine if any security specific training might be needed. This is similar to any other technical training that might be needed by the engineer assigned the story.
Security During Design
As stories are selected, teams then move on to formal or informal design as they determine if any infrastructure changes are needed, what software architectures and integrations will be used, etc. During this phase, I ask teams to consider three questions which shouldn’t add significantly to the workload:
- Does this story change where we are ingesting or outputting data? If so, update the data flow diagram.
- Does this story change our potential risk profile, or create new threats? Take some time to update and review the threat model.
- Is there anything in this story that we might want to review formally or informally with a security expert?
Security During Development & Test
- Integrate a static analysis tool into the IDE whenever possible. SonarQube can be configured this way, along with many vendor SAST tools. This allows developers to see security bugs in near real time, minimizing re-work and maximizing learning.
- Integrate Dependency / Open source security checks into local build processes whenever possible. This will catch vulnerable dependency versions as soon as they are added to projects in one team members machine.
- Integrate both of the above into a CI/CD pipeline, and break the build on issue thresholds. This way, if someone on the team isn’t running the tools locally, you can at least enforce security prior to any deployments.
- Configure dynamic test tools into the CI/CD pipeline on deploys. This one can be a little trickier to setup. To get started with this, I usually recommend configuring a ZAP baseline scan integration, or using your DAST vendor tools. Additional dynamic tests can be added over time.
Security During Deployment
- Updating any out of date application components (for instance, rolling patches into a docker container before deploying the latest changes)
- Considering if any changes being deployed require changes to our alerting / monitoring / logging / prevention infrastructure.
A Security Automation Roadmap
- Have security professionals join some sprint planning meetings to get a feel for the functionality of the application. Work with the team to develop an up to date threat model and data flow diagram.
- Teach the whole team basic threat modeling and try to get them thinking about it each sprint cycle.
- Determine if applications teams are using CI/CD. If they are, work with the build engineers to integrate static analysis into them, in a non-build-breaking manner. Start with SonarQube & DependencyCheck if your organization doesn’t have a SAST vendor.
- Work with one or two engineers to integrate SAST into their IDE. Based on the outcome, consider attempting to get all team members to adopt this flow.
- Setup CI/CD integrated dynamic scans. Start with the ZAP baseline scan or your own preferred DAST vendor tooling. If CI/CD is not setup for the team yet, try to configure a regularly scheduled scan.
How to integrate security in agile projects – the first, effective step (By Dagmar Stefanie Moser)
Simple Example: An Online Shop for City Tours
Simple Example: An Online Shop for City Tours
Security Story 1
- As a customer of the webshop I would like my personal information to be protected from access by third parties so that it can’t be exploited for their purposes.
Acceptance criteria for 1
- Ensure that the transfer of data from the customer’s browser to the web server is encrypted with TLS 1.3.
- Ensure that only authenticated and authorized users have access to customer data via the webshop.
- Ensure that only authenticated and authorized users have access to the database.
- Ensure that communication between application components, including API and database, requires authentication.
Security Story 2
As the owner of the webshop, I want to be the only person able to create and modify information in the online store, so that my offerings can’t be manipulated by third parties.
Acceptance criteria for 2
- Ensure that the shop owner has to authenticate herself with a name and a password.
- Ensure that the shop owner must choose a password of at least 12 characters long.
- Ensure that the password is checked against a list of known compromised passwords when creating the account and choosing the password.
- Ensure that the shop owner can change her password when desired.
- Ensure that the shop owner receives an email when her login details are changed.
Top 6 security best practices for agile development environments (By Mehmat Khalid)
1. Utilize the hacker in that developer:
Not every developer is a hacker, but every developer with the right tools, training and mindset can uncover the most common security pitfalls in code. If your systems will be secure, the developers must be empowered through training and the provision of the right tools that will enable them to analyze code before submitting it to quality assurance or testing teams.
All development team members must be aware of the most common vulnerabilities in each system they develop. They can then perform routine scans of their code and fix any issues that may arise during the core development process.
2. Always consider the “evil” user interacting with the system:
Many developers get carried away with the expected functioning of the system. They envision a perfect software without taking into account the possibility of an “evil” user interaction. Therefore, team leaders must discourage this form of tunnel vision by ensuring that team players are aware of the possible ways an attacker may interact with the system.
This is a continuous process starting with the statement of security-based user stories. However, note that only a few clients will talk about this type of security in user stories. Therefore, it should be the security team’s role to identify critical points and valuable assets of the software that may be targeted by an attacker.
3. Uphold continuous integration practices, tools and platforms:
There are various tools designed to integrate with your development platforms and give insightful information about your code. These include code integration tools, code scanners and shared repositories. Code analysis tools are especially useful for the security of your code, as they can help you debug and refactor buggy code, thereby improving the system’s overall safety.
Upholding continuous integration best practices should never be optional for any agile development team or organization. These are practices that work and help improve the quality of the software you create, thereby assuring the security of users, user data and vendors.
4. Review user stories with every iteration and adapt as necessary:
Agile methodologies are defined by short iterations in the development process, resulting in the release of new or improved software system features. Therefore, it is possible to review all user stories that necessitate iteration and how they relate to the system’s general security before releasing it for public use.
The team leader must also organize peer review of code and how frequently this occurs. Two pairs of eyes are often better than one during code review. The software must be adapted to better its reliability and security if vulnerabilities are discovered in the review process.
5. Innovate with security:
One of the reasons why agile systems neglect security is the absence of robust, agile security practices and testing tools. However, progressive teams can avoid this by innovating workable security policies and developing tools based on such policies.
Most CI tools out there are open to customization. Therefore, an organization or team can choose a tool that works with their development practices and customize it to serve the most common security concerns affecting their code. Innovating is a long-term plan and may not be viable for starters.
6. Cultivate the culture of security:
Organizational culture profoundly influences how things are generally done. If team leaders have high regard for secure systems, the juniors are likely to copy the same and practice it when writing code. Educating the team and organizing seminars for security and agile development can also help members adopt the security needs of software quickly.
Every new team member should be taken through the necessary software security procedures and guidelines you follow as an organization or as a team. This helps them get up to speed with as little difficulty as possible. Furthermore, combining all the other security aspects of agile development with a supportive and dynamic security culture will boost the general feel of your software.
- What is DevSecOps?- Shannon Lietz
- DevSecOps Defined, Explained, and Explored – Cyber Edu
- Security Is Awesome – Charlie Belmer
- Challenges and Opportunities: Security in Agile Software Development – Dagmar Stefanie Moser
- Top 6 security best practices for agile development environments – Mehmat Khalid
Back to Blog