Why DevOps Teams Need to Understand Cyber Security
Read on to learn why the security side of the coin shouldn’t be applied after the application is developed, but during the developmental process.
Join the DZone community and get the full member experience.Join For Free
Without thinking twice, mixing DevOps and cyber security is really tough to do. The goal of DevOps is to go as fast as you can. However, in security, we are taught to proceed with caution. Both of these fields serve a higher authority — the business clients — and the businesses will only be served if and when DevOps and security learn to get along together.
Security-minded coding should be thought of first when it comes to the DevOps process, which is also can be called DevSecOps. Cybersecurity specialists understand how applications and data move from development and testing to staging and production, as well as how to address weaknesses along the way. At the same time, the DevOps teams must understand that security is partly their responsibility, also, not just slapped onto the application at the end of development.
Now, we can talk about the terminology that is needed for DevOps people to be more aware of security and how it affects everyone. This is just a start into the world of security when it comes to computers.
Denial of Service (DoS)
The denial of service attack is used to deny users from getting service from systems. It is used in a variety of methods that place a horribly massive load on the servers, applications, and networks. This can cause them to crash. The majority of DoS attacks are distributed (DDoS). DDoS attacks are much more difficult to block because they don’t originate from a single IP.
That being said, even a single DoS attack from an IP can be devastating if it comes from within. An example of this is a container may be compromised and used as a platform to repeatedly open processes or sockets on the host. These attacks can cause the host to crash.
Vulnerabilities vs. Exploits
A vulnerability is a weakness that can allow an attacker to compromise a system. They usually happen to due bad coding or programming errors. They are basically bugs. At times, they don’t interfere with normal operations of the application, except to open a door into the application or server.
Whenever you use any open-source software, you should take notes and scan for known vulnerabilities (CVEs). These can be usually fixed by updating the affected components to newer versions that are patched. In a few cases, it’s possible to neutralize the risk posed by a vulnerability by changing configuration settings.
Exploits are code that exploits the vulnerability — also known as a hack. Most of the exploits that I work with are found by fellow white hat hackers and patched before they have ever been used. If an exploit has been used, then it is known to be "in the wild."
A situation in which a known vulnerability has an exploit in the wild and has yet to be patched is obviously to be avoided.
Zero-Day Vulnerabilities vs. Known Vulnerabilities
Vulnerabilities in open-source software can be resolved by the developers. The fixes will be released to all users before malicious users become aware of them. Such known vulnerabilities are recorded on the Common Vulnerabilities and Exposures (CVE) system, operated by MITRE.
In my line of work, hackers usually find vulnerabilities before they’ve been revealed and patched. These zero-day vulnerabilities are the most dangerous to deal with yet aren’t that common to have to deal with.
Least Privilege Principle
I try to live by this standard daily with all of my projects. The principle tells us that users and applications should only have the access to the minimal information and resources that they require. This will prevent all system misuse. It also states that if you only have access to what you need, then the damage will be limited if you are compromised.
Applying this will dramatically reduce the spread of malware. I usually perform checks in permissions for all groups and accounts on my system at least once every three months to make sure that they are set where they need to be.
In a DevOps environment, it’s important to separately define access privileges to development, testing, staging, and production environments, minimizing the potential damage in case of an attack and making it easier to recover from one.
Advanced Persistent Threat (APT)
An advanced persistent threat is an attack that often may take months to years to unravel. As an example, an intruder will find a point to break into a system — usually using a vulnerability — and plant code that will collect network traffic or scan for other processes on the host. Using the data that was collected, the attacker will most likely dig deeper into the network. This process can continue till he finds something valuable. This could be customer data, financial data, or something to use against the target.
APT is not a single attack, but a combination of many different methods. There really isn't one single way to protect yourself against it. In cases like this, you must have multiple layers of security and be alert to anomalies.
In the world of DevOps, this is way more difficult because they are anything but static. So I would suggest applying the least privilege principle religiously, causing your development and production environments to be difficult to breach. Plus, you’ll want to monitor your applications for highly abnormal activities.
The terms above make a very small list, but one that we all need to keep in our heads. Also, by the same idea, it is important for DevOps teams to understand security better. The security side of the coin shouldn’t be applied after the application is developed, but during the developmental process. Learning to speak the lingo is a good start to security for a DevOps team.
Published at DZone with permission of Traven West, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.