DEVOPSdigest

It is important to not only pay attention to product delivery automation and speed but also to add security to software updates, critical system vulnerabilities, and correct system access control, which DevSecOps practices assist with.

Start with DevSecOps Best Practices and Business Value - Part 1

The following are 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.

Digital signature

A DevSecOps practice 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, should be authorized and trusted by the system.

System control versions should 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 a source control system has these digital signature capabilities it should be using them to ensure that the code in the 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 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.

Open source applications like OWASP Threat Dragon or Seasponge may help. 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.

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 a system is under attack, it should provide information about the entry point and escalation process for all affected systems

Various software or hardware solutions provide information on penetration. If network penetration has occurred, then this problem is usually solved by the IDS/IPS system, which allows for the detection of 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 teams 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 of this data allows teams to analyze and identify the entry point and escalation process.

For cloud native solutions and organizations 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 range of security tasks or serve as mechanisms in the process of ensuring information security.

2. Monitoring abnormal behavior

To monitor abnormal behavior, it is critical to know the system's normal state in order to 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.

Let's look at an example of a database inside Kubernetes when there is an attempt to gain access. When this happens, create a rule: send a notification when there are more than 30 attempts per one minute to gain access, which means that normal behavior, or "white list," will include less than 30 attempts per minute. A DevOps team 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 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.