Tech Insights

DevSecOps Best Practices and Business Value

Aliaksei Kulik

June 9, 2020

#DevOps

About DevSecOps: DevOps and Security

DevSecOps brings together the best of DevOps services with modern security practices. DevOps streamlines and accelerates the product development lifecycle, aiming to automate as much as possible. DevSecOps practices maintain this automation focus and incorporates security — with a goal of making each step secure and bringing in new tools and practices to make the entire product more secure as well.

Today with maximum automation it is essential to integrate security. Leaving security as an afterthought is a non-starter and could be very costly for a business and its customers. We’ve all read the headlines related to fines, reimbursement, and lost business that comes when a large company is compromised or breached.

Considering DevOps and security separately from processes can also lead to delays in the delivery product features, because vulnerabilities have to be assessed separately. These delays run counter to the goals and promises of most DevOps groups and organizations.

For example, if a large enterprise with billions of dollars in revenue processes a large quantity of user data and stores that sensitive data in its databases, it is critical to make sure early on that this kind of information can’t be hacked. If hackers are able to take total system control and start to exploit the system’s vulnerability by getting access to the servers and having the possibility to access and save users’ data, this could lead not only to data loss but also to a large expenditure and fines. That’s why it is significant to not only pay attention to product delivery automation and speed but also to secure and timely software updates, critical system vulnerabilities, and correct system access control, which DevSecOps best practices assists with.

This article will focus on some established DevSecOps best practices and emerging ways that DevSecOps best practices are coming to play a prominent role in product delivery organizations.

DevSecOps Best Practices:

  • Principle of least privilege (PolP)

    DevOps teams should always follow the principle of least privilege (PolP). This means if any automated system or account needs to be given privileges by another system, the requesting system should be given only the access that is needed to complete the work. Most requesting systems or teams should never be given full permissions, root, sys admin, or any other role that provides them with much more than is necessary. This is true even if it means that multiple requests will be made later for additional permissions, and even when teams and managers protest.

  • Digital signature

    DevSecOps practices should concern itself with security during all steps previously touched by DevOps processes and personnel. Developers who are going to be writing new code, or changing existing code, are authorized and trusted by the system. Today system control versions have not only access authorization functionality, but also digital signature options. Only trusted people with a digital signature may transfer their changes to the code in the master branch. DevSecOps best practices dictate that if your source control system has these digital signature capabilities you should be using them to ensure that the code in your system is only added/modified by a trusted source.

  • Security tests 

    During Continuous Integration (CI) security tests can be performed. It is difficult and time consuming to check large code bases manually for security vulnerabilities. Using security testing helps save time and effort. As it’s often impractical to check the entire code security manually, especially when it comes to code built for enterprise products, there are systems for such security tests that help save DevOps teams’ time and effort. Both static application security testing (SAST) and dynamic application security testing (DAST) can be performed as part of the CI workflow. SAST examines the codebase for vulnerabilities by peering into the code itself and looking for problems such as SQL injection. DAST requires a running version of the product and it is tested by attacking the working system and making sure it isn’t vulnerable.

  • Detecting Common Vulnerabilities and Exposures (CVE)

    There are several organizations whose products help to make sure that the code or containers are secure, preventing common vulnerabilities and exposures. There are also non-commercial organizations, such as the Center for Internet Security (CIS), that provide security benchmarks for free with detailed installation descriptions and instructions. This helps teams to check the system’s security level, understand common vulnerabilities and exposures of configuration, and conduct semi-automated or automated testing. There are also algorithms and tools that allow teams to initially define the security logic within the code. Such process is known as Threat Modelling, the main idea of which is to architect a safe application solution from scratch and analyze all possible vulnerabilities methods for existing applications. By creating threat modeling for an application with necessary security steps, you concentrate your attention on possible weaknesses in advance. Here such open source applications as OWASP Threat Dragon or Seasponge may help. Today there are also third party products that allow developers to securely save and retrieve passwords, allowing teams to outsource password security and maintenance to specialist providers.

    DevSecOps is very specific and detailed in its application, and this is important. Following common vulnerabilities and exposures for the EXACT products and tech used in the infrastructure helps teams avoid, isolate, and fix issues that crop up for their particular situation.

  • Monitoring

    Once a product’s code has been placed in source control and deployed, the system needs to be monitored.

    It is important to distinguish between traditional infrastructure and system monitoring (even smart monitoring) and security monitoring.

Security monitoring needs to fill two key roles:

  1. If you are under attack, it should provide information about the entrypoint and escalation process for all affected systems.
    Various software or hardware solutions provide information on penetration. If we are talking about network penetration, then this problem is usually solved by the IDS/IPS system, which allows you to detect an attempt to penetrate and further spread along the internal perimeter of the network. Systems based on the analysis of events from the host system allow you to identify clearly prohibited actions, for example, executing a process from root, or repeated attempts to enter a password, check the availability of network ports, and attempt to communicate over prohibited ports and protocols. All this data allows us to analyze and identify the entry point and escalation process. For cloud native solutions/organization there are mechanisms, which are ready for collection and analysis. For example there are Cloudtrail, Cloudwatch, Lambda and other services for AWS that allow you to implement a huge range of security tasks or serve as mechanisms in the process of ensuring information security.
  2. Monitoring abnormal behavior. To monitor abnormal behavior, we need to know the system’s normal state. When we know it, we can make rules which will detect any unusual cases. The reporting here will allow the DevSecOps team and developers to take appropriate actions (modify existing rules or write new ones) to avoid future attacks. For example, we have a Database inside Kubernetes and there is an attempt to get access to it. We created a rule: send notification when there are more than 30 attempts per 1 minute to get the access, which means that normal behavior, or “white list” will include less than 30 attempts per minute. All in all in this case, a DevOps member can build a middleware service that will accept all incoming communication from the application and check the status of the Database. A SecOps team member can create a “white list” with allowed applications, verifying a hash sum docker container and who is the last person who pushes a container to a registry, plus adding a secure transport layer and a certification authentication between all applications. Finally, a DevSecOps member may use all the approaches mentioned above and automate the process, by creating security rules and one authorization service.

DevSecOps Business Value:

Above we’ve described several DevSecOps best practices and the positive impact of DevSecOps processes on business, to recap:

  1. Ensuring the payoff of automation — by including security testing, we make sure that vulnerability testing doesn’t become a separate process that slows down feature delivery.
  2. Avoiding System Compromise — utilizing all the tools in the DevSecOps handbook, we make an attack or compromise less likely. This limits the business’ exposure and keeps customers happy.
  3. Fast Reaction — when an incident does happen, having the appropriate monitoring in place helps us react quickly and address problems proactively, thereby reducing the risk of a catastrophic incident and helping prevent exposure of critical data.

DevSecOps processes can help in other ways as well.

DevSecOps processes can also assist with corporate compliance. If a company has sensitive data, it probably falls under some type of compliance structure. PCI-DSS, GDPR, HIPAA were all created to protect important data of (various) system users. PCI-DSS compliance, in the financial sector, ensures sensitive data security and system non-vulnerability for systems that need to store or use cardholder data. If the organization has non-compliant systems or code, it can be penalized, which can be quite financially painful and potentially lead to a loss of customers.

The General Data Protection Regulation (GDPR), a European privacy regulation issued in 2018, guarantees personal data protection. Before it, any internet resource could save personal data and organizations were not required to delete or manage this data. This could be true, even long after a user ceased using a particular system. Users also didn’t have the right to request that their data be deleted. Now, the GDPR obliges organizations, upon the user’s request, to delete personal and other data from their storage systems. If the organization doesn’t do this, it can be subject to substantial penalties. Here you can see that applying DevSecOps practices can help organizations escape challenges with personal data security, which will ultimately help to decrease reputational and financial risks.

As DevSecOps practices grow in popularity, it is being used by many enterprises as an important part of their DevOps and security practice. Companies such as Google and Mozilla publish books that help teams stay informed and updated on the securities issues in DevOps. (for example, “Security DevOps: Security in the Cloud” by Julin Vehent, Building Secure and Reliable Systems)