Basic Knowledge Devsecops

DevSecOps is an extension of the existing approach of placing development and operations in a single team. DevSecOps also places security in the same team, giving it a central role.

With DevSecOps, you generally move from a world in which most services are managed centrally to a world in which services are only made available. This also strengthens the principle of Infrastructure as a Service (IaaS).

Age of complexity

From the decision to launch a product to the decommissioning of this product, the question of how to guarantee its security arises time and again.

Below are various options in the area of DevSecOps, which should serve as points of reference for teams who want to reach their goal securely and quickly.

Basic rule 1: Processes over tools

For a DevSecOps team to be successful, it must receive regular feedback and be able to implement changes quickly. DevSecOps processes must be able to be adapted quickly. This is particularly important for the following reasons:

• Frustration in DevSecOps teams increases rapidly if processes can only be adapted weeks later.
• When an application is launched, there are always many change requests. If these cannot be implemented soon, they reach a critical level after just a few months.
• DevSecOps teams cannot work independently if lengthy feedback processes slow them down.
• If the processes are too complex and cumbersome, DevSecOps teams will find ways around them.

When introducing DevSecOps in your company, it is best to focus on individual areas and get started here. Switching everything to DevSecOps overnight is neither necessary nor sensible. The teams need time to settle in.

Basic rule 2: Master the tools

DevSecOps teams must master their tools. The following must be observed:

• For tools to be used effectively, they should not be replaced too often.
• Tools should be used to automate tasks and save the teams tedious work.
• The tools should be as familiar as possible to the teams. Assistance for correct use must be provided.

The choice of tools is therefore of great importance. Depending on the requirements situation, in-house developments can also be worthwhile. Netflix, for example, developed Chaos Monkey, a tool that randomly shuts down instances (containers and virtual machines) - a good stress test for high-availability solutions. Anyone developing their own solutions should consider making them publicly available via GitHub, GitLab or other platforms. It should not be underestimated how much positive reputation you can build up in this way. In addition, you can sometimes come into contact with applicants who would otherwise never have heard of you.

The Sec in DevSecOps

When it comes to DevOps, the rule is: automate, automate and automate again. The same principle should be followed for the Sec in DevSecOps. With the help of ticket systems and mature processes, new features can be implemented quickly in an application. The same means can also be used to strengthen security.

Leading teams with an agile approach means making security an integral part of the existing setup. It is advisable to define champions who specialize in the topic of security and exchange information with other teams in this regard. The first need for action can already be defined in the sprints when laying the foundation stone for building a solution. Solutions can be found that are re-evaluated again and again. For example, the issue of transport encryption in the company can be addressed again and again. Is TLS 1.2 still the state of the art? A Champion addresses this issue and, for example, advocates the provision of ready-made configuration files that can then be used by other teams. The other teams then no longer have to fight their way through a cryptography policy, which often leaves many questions unanswered and requires them to ask the Chief Information Security Officer (CISO). The configuration files can also be made available centrally in the repository. This also makes it easier for the CISO or third parties to carry out an audit. You can also consider publishing configuration files. This may make it possible to be found on the first page of a web search.

Collected knowledge

A collection of knowledge on the intranet is used by all employees in the company and is also maintained by some of them. However, it makes little sense to force DevSecOps teams to use the intranet. As a reminder: Basic rule 2 above states that DevSecOps teams should use the most suitable tools. If the intranet is not maintainable via a Git repository, documentation on tools, configurations and more will be very tedious to maintain. If you use a simple knowledge repository on the intranet, updates will be missed, changes across multiple versions will be difficult or impossible to track effectively and automation will not be possible.

Most DevSecOps teams will want their knowledge to be stored and maintained in a public repository. If the teams cannot store their documentation with a reliable repository provider (Git Push to GitHub/GitLab), this leads to problems in the later life cycle.

You should also make sure that knowledge is stored effectively. If you rely on important information from third parties, you should store a copy of this information in your own system. You never know whether publicly available information will be deleted or blocked at some point. Automation can also help here: You can always make a copy and be informed of any changes or deletions.

Platform security

If you rely on a platform, you should make it secure for all your applications. Working in insecure environments will sooner or later lead to problems. For example, if the DevSecOps team just needs to make a quick change or check something small, this is usually quicker and easier in the insecure environment. The next person repeats the same steps and is unaware of the risk this creates. Investing in a comprehensive secure environment is a one-off effort that pays off in the long term. It also reduces the cognitive burden on teams - they don’t have to decide on the right environment with the right tools and processes for each individual case, but have everything in one environment. It is best to follow a standard when setting up a secure environment.

For very strict environments, monitoring could be an option, in which the platform is checked for several points:

• Standards and Benchmarks:
  • Application Container Security Guide NIST 800-190
  • Securing Docker CIS Benchmark
• Host Hardening:
  • OS Hardening, including CPU/Memory Isolation Features
  • Automated daily patching
  • Monitoring & alerting of base services
    • Tracing & timing
    • CPU, RAM, disk usage limits
  • HIDS/HIPS
  • IAM connection
  • network
    • Access only after authentication
    • Host firewall
  • Disk encryption
• Container:
  • Established standards for images and use
  • Integrated features and configuration
    • Monitoring & alerting
    • IAM connection for system users
    • Firewall

Identity and Access Management (IAM)

We at TEMET have been dedicated to the topic of IAM for more than a decade. On our homepage you will find several articles on this topic. We would like to emphasize three points to which you should devote more attention in this context. These points are considered in the following chapters.

The article Central authentication and authorization management - an opportunity for the future provides good basic knowledge on the subject of IAM.

Passwordless

Like paper, the password is slowly becoming overdue. Compared to alternatives that do not require a password (passwordless), the password offers less and less security. It has become too difficult to remember all passwords in the jungle of systems. People prefer not to choose long, secure passwords because they have to enter them too often. Step-up authentication using an additional factor is simpler. Imposing complicated password solutions on DevSecOps teams does not strengthen your protection, but rather harbors risks because workarounds are found to circumvent password entries.

Therefore, always ask yourself the following: Does it make sense to work with step-up authentication in the case under consideration, or is a password necessary? Are there tools that could make your life easier, for example by storing PGP keys on a FIDO2 device?

You can find an interesting article on this here: After Paperless comes Passwordless.

Identity Provider

The question of whether a separate identity provider is required is usually asked very early on and often answered with “yes”. In this case, however, all applications and services that are newly introduced must be connected to it. Isolated solutions soon lead to problems and should be avoided. For example, the entry and exit of employees becomes problematic due to isolated solutions. If you use an identity provider, you should make sure that it is not only available in the company network, but also externally.

Secrets / Vaults / HSM

Today, IAM involves much more than just role management. Certificates, security credentials and secrets must be used. Key sharing and hash signing** are topics that need to be considered here.

With Key Sharing, a key is shared with other team members for signing. For example, application versions that have been checked and released can be marked as trustworthy.

Hash signing** should be a standard tool for increased maturity. With hash signing, the source code / source file is provided with a fingerprint (hash) and signed using a signing key. Only with this signature is the code or file considered trustworthy. This prevents foreign code from being infiltrated in the event of a hacker attack.

Network

When it comes to networks, there are various security-relevant trends that need to be taken into account. IPv6 is just one example of many. Precisely because trends are constantly changing and services are being operated in an increasingly decentralized manner, classic perimeter thinking is no longer applicable. A web application firewall (WAF), which may be running in your data center, is not available locally on the programmer’s machine or is missing when deployed in the cloud. New solutions must therefore be used.

Service Mesh Hardening

Communication between the containers (inter-process communication and service communication) takes place via a service mesh. Successfully managing this is a skill that every DevSecOps team must acquire sooner or later. In this context, it is particularly important to note that ingress and egress controls are best configured automatically. As soon as service mesh services are deployed, they should be controlled via configurations delivered by the various DevSecOps teams.

Zero Trust may not be so important at the start of a service mesh service. However, it soon becomes essential as your team grows in complexity. Finding the right configuration and not overlooking anything quickly becomes impossible in complex environments. With increasing complexity, it also becomes more difficult to detect when there is suddenly a lot of traffic on a network, as there is no longer a central point of contact that is informed about the use of services. But it is precisely this sudden increase in traffic via open connection points that have been forgotten that can be used by hackers to steal data from the system. Zero Trust should not be seen as a substitute for other security measures, but as a guiding principle when operating a service mesh.

Connection with transparency

With DevSecOps, the classic configurations in which routers, firewalls and switches are accessed via a CLI will become obsolete. Various manufacturers are already supplying “edge routers” that configure themselves independently via the cloud using various parameters such as IP addresses. This shift from a configuration that is made directly on the device to Infrastructure as a Code (IaaC) is one of the biggest challenges of the future - one wrong routing setting and the entire data center is offline. DevSecOps teams can learn and implement new technologies with incredible speed, but when it comes to networking, you will need to create a team of Network Excellence Operators. This team will take an in-depth look at the changes in Software-Defined Networking (SDN), identify and resolve bottlenecks and overcome parameter challenges (e.g. handling jumbo frames).

The Network Excellence Operators team must deliver two things to keep the network infrastructure running smoothly:

• Best practices for the teams
• Transparency in the network

The latter includes not only in-house network monitoring, in which endpoints are pinged and latency times are measured. There is also a large number of analyses that need to be made available to the other teams. Anyone developing a service not only wants to monitor it, but also to be able to check the plausibility of the monitoring results. A web service that returns 200 status codes can provide valuable services here. In this way, network operation in layer 4 of the OSI model can be combined with the possibility of carrying out monitoring without having to provide your own services.

DevSecOps: long-term perspective

DevSecOps requires services to be made available as “as a code”. At the moment, opinions are still divided on the question of what a team can decide independently and what must be approved in writing by a central team before execution. In fact, there are hardly any things that really need to be approved centrally. This is actually only necessary for decisions in the areas of IAM, PKI and network. When selecting the infrastructure (on-premise, cloud or hybrid), container technology, code frameworks and data models and many other issues, the teams must develop a maturity that allows them to move independently. It is important to remember the principles mentioned at the beginning. Don’t hold your teams back with fixed processes. Lead by example and adapt processes based on feedback from the teams. If you don’t do this, you will decouple two worlds within your company: the DevSecOps world and the rest of the corporate world. A good process will help you more than any compliance tool that ends up reporting incorrect figures because nobody understands an application. Wherever you use tools, you should set yourself the goal of mastering them. A larger fleet of only half-used tools will not make your teams faster, but will make their work tougher and more complex and thus expose them to greater risks.

We can help you build an effective DevSecOps team that benefits your entire organization.

Risk Management Identity and Access Management (IAM)

About the author

About the author

Daniel Brunner, Senior Security Consultant