DevSecOps: Building a Culture of Responsibility for Network Security
Security vulnerabilities are everywhere.
If nothing else, the recent hack of Equifax that compromised approximately 143 million American credit records is a signal that even our most trusted networks are vulnerable.
However, security breaches are almost always the result of the exploitation of a simple vulnerability. The best firewalls in the world can’t stand up to valid credentials. In fact, there is emerging evidence that perhaps the Equifax breach was the result of an easy-to-guess password.
Getting Everybody Involved
The most important piece of DevSecOps, as with any departmental integration strategy, is communication.
While the concept of DevSecOps may seem or feel new to your development and operations teams, your security department will probably say, “it’s about time.”
This is because network security is not the responsibility of a single person or department. It’s the responsibility of every person who works behind your firewall. Your cybersecurity staff has understood this all along. Meanwhile, the rest of your team has been happy to pass the blame over to your security department.
When your organization makes the changes and deploys a DevSecOps strategy, you’re really asking your entire technical staff to make security a top priority, among development, deployment, and operations in importance.
If you talk to any security expert, they’ll tell you that this is the only way to secure your network.
Security in Development
The development side of security is important for a number of reasons.
Program design is where security vulnerabilities first appear. Getting your security staff involved with program design is an important but arduous process. It’s important that your development team is able to accurately and clearly communicate database, data warehouse, and application interactions with information security personnel to solicit valuable input.
An excellent way to clarify system design and information flow is with an automated program architecture analysis solution. This is a way of generating a visual representation of program design and flow automatically. Not only is it helpful to developers as a time-saving tool to create insightful visuals, but it’s exhaustive, meaning it won’t miss any important details.
To security professionals, this is incredibly important. Often, the “loose ends” of data flow design can end up being dangerous vulnerabilities.
A developer may be satisfied as soon as the system works, but it’s important to provide your developers with automated visualization tools and the audience of your security staff before deploying a product to ensure its integrity.
The most common security vulnerabilities that developers build unintentionally are:
- Weak Authentication Protocols: While your development team will actually build the authentication processes into your applications, your security staff should decide what protocols are appropriate. It’s a balance between the sensitivity of the data and the number of authentication factors your IT staff are willing to endure, but it should ultimately be up to your security staff how robust your authentication protocol is. A leaked username and password should not be enough to compromise your entire database.
- Unprocessed Input: Your applications should never respond to end user-level input directly, especially if accepting input from unauthenticated parties. This is a common vector for the OWASP AI type attack, known as injection, which can fatally compromise entire databases. Input URLs are a common source of unauthenticated inputs. Your security staff should have input on the processing that user input goes through before your application engines take that input.
- Race Conditions: Any program flow that requires a specific order of events is known as a race condition. Clever hackers can exploit race conditions by instigating order-related bugs and exploiting system crashes (such as data delivered by error messages) and use it to exploit your system further. It’s important to avoid race conditions. Minimally, they can be handled with redirects.
- Others: There are, of course, too many vulnerabilities to list here. A more complete list of such vulnerabilities and the way our automated code security analysis system detects them can be found here.
The beauty of DevSecOps is that it gives your development team the opportunity to learn from your security staff about the specific vulnerabilities that are problematic in your previous deployments. This will help your development team improve your products’ security features in future versions.
Security in Operations
While development is arguably the most important DevOps piece for DevSecOps, Operations still plays a very important role.
Your operations team will handle most of the issues around user authentication and day-to-day dealings with sensitive data. That’s why it’s important that your operations team has regular contact with security staff. Ideally, they should meet every week.
Security-Operations (SecOps) meetings should cover:
- Anomalies: Some failed attempts to breach your network are registered as anomalies. These can be failed authentications, unusual session lengths, and other unusual session behavior metrics. Every week, your SecOps meetings should talk about the anomalies that were detected that week and their outcomes
- Security Culture: The DevOps team is in a unique position to address the corporate culture and attitude around security. It’s a topic that falls squarely into their intersecting disciplines. Security best practices are the responsibility of every team member, not just security and operations. For an actionable result, your DevOps meeting should produce a weekly security memo that reinforces your corporate security culture.
- Identify and Address Conflicting Interests: Very often, security best practices can get in the way of productivity by slowing down access to sensitive data. Your operations team should use these meetings as an opportunity to voice their concerns about security practices and listen to your security staff. Often, a working solution that meets the needs of both parties is within reach.
- Application-Specific Details: Depending on the nature of your network, there will be important details that are specific to your organization. SecOps meetings should cover these topics by working on a preset agenda. At the end of the meeting, your SecOps team should come up with an agenda for the coming meeting. This will keep the momentum going on your overall strategy.
DevSecOps is All About Communication
As with DevOps, DevSecOps is the intersection of important departments that fosters innovative solutions.
It’s really all about getting the right people into the same room and coming up with creative ways to reach effective outcomes. Along the way, subtle changes to your corporate culture around security practices can make all the differences in preventing a major security breach.
