Without thinking twice, mixing devops and cybersecurity is really tough to do. The goal of devops is going as fast as you can, while in security, we are taught to proceed with caution. However, both of these fields serve a higher authority — the business clients — and the businesses will only be served when/if 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, and 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 about security and how it effects everyone. This small just 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, 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 ti 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 which may allow an attacker to compromise a system. They usually always happen to due bad coding or programming errors. They are basically bugs, at times 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 which I work with are found by fellow white hat hackers and patched before it has ever been used. If an exploit has been used, then it is known to be in the wild.
he situation where a known vulnerability has an exploit in the wild and has yet to be patched is obviously to be avoided.
Zero Days 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)
Advanced persistent threat is the name given to attacks 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. So 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 to apply 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 is a very small list, but one which 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.