In this and final post about DevOps basics, I am going to discuss application security through devops or DevSecOps. Although all the information in this blog post is self-contained if you are new to devops subject I highly recommend to go through my previous two posts of this series.
Security is often an overlooked aspect of software development and that is what provides a lot of hackers an advantage. It is not easy to catch security loopholes within an application or the infrastructure even the developers who have to build various systems can often leave one or few major security gaps inside their application. An application went through a rigorous penetration testing will be many times more secure than one not. Devops is no exception, nobody wants their CI/CD pipeline to be highjacked and hackers are able to bundle their viruses and malware into your builds. If your user finds that your application is misbehaving or collecting their private data sometimes in extreme cases even mining cryptocurrency inside their system, they would lose their trust on your brand and will quickly move to another competitor of yours, no business would want that.
Secrets and credentials
As we would probably agree, there are various phases in DevOps, requiring a different level of security and caution while handling the structure of that module. So this goes without saying, all the teams will be different in these phases following their own way of security management. For example, in the construction phase, a team generally shares keys and secrets through mail or stores them in the disk. It’s also possible that keys are cached in the browser cache. Another common case can be when sensitive information is present and gets pushed to repositories that are shared and which different departments have access to. These are very common approach generally followed by smaller teams or companies that just want to get their product out. And that’s why, security is not given much priority as they’re not sure about the success of their product’s result, also that they do not have many secrets, to begin with. This initial protocol team follows might weigh a breach in terms of probability and what it might cost them (downtime, defacement, etc).
So, teams at this level have no constrictions and can move fast without worrying about security. What teams do not realize is that smaller companies are highly susceptible to simple information extraction emails, such spans, and phishing attacks. And in case any of such attacks are successful, recovery of credentials and secrets requires a lot of capital and manpower, which smaller teams simply do not have. Therefore, it is a necessity to build a culture around awareness of cybersecurity and begin training employees to start production by taking such points in mind.
Usernames and passwords
One of the biggest fear of security teams is to discover that their engineers have chosen passwords like the lines of “GoogleInc”. The problem is that by using such common and easy to guess passwords, the organization has increased risk not only for their data leakage but also attack-surface many times fold. Also, many times teams move fast but do not have a streamlined approach for rotating passwords. This is especially problematic in case an employee decides to leave the team or the organization. If the team is not responsible for this, the employee will still be able to retrieve all the companies secrets at their will. So, practicing proper secrets does not only protects against external threats but also against the internal ones.
A popular practice in Puppet includes a built-in key/value lookup system, Hiera. Hiera, with a hiera-eyaml backend, can be used to encrypt sensitive data within YAML files. Another feature of Puppet includes sensitive data tagging ( Sensitive[T] and unwrap). These features protect sensitive data from accidental leakage or logging. Often CM Systems use single-key encrypted storage for secrets. Therefore, it cannot guarantee that every secret is protected and accounted for. Assets need their passwords on-demand without reliance on third-party software. Although a configuration manager is a step in the right direction, it is no vault.
Other types of secrets (certificate) and Network Security
If keys and certificates aren’t protected, cybercriminals can easily use them to get around your security. The only way to prevent a compromise, an outage, or evolving a PKI is a constant vigilance. There are organizations like Venafi, which can ensure this protection. A very common mantra to be followed is to Secure Trust. Limit Exposure. Respond Quickly. Every organization is completely dependent on keys and certificates for safe and private communications, commerce, computing, and mobility. The fact that all safety is guaranteed by such keys and certificates, is the prime reason they ’re prime target for cybercriminals, who use them to bypass traditional security controls.
Common steps to be undertaken for ensuring safety are to Identify all keys, certificates, CAs and trust stores. Continuously monitor keys and certificates for any and every anomaly or intrusion.
Instantly and quickly changed compromised keys and certificates. Make sure that key and certificate policies maintain security. Automate the entire process of certificate requests and renewal.
Lots of online posts and documents portray Docker is inherently insecure and not safe for industrial use. Although there indeed are ways in which containers can be manipulated and misused, if used properly, dockers can provide a much more safe and efficient system than using a VM.
For making sure our container is safe, we need to be aware of the potential security issues and the important techniques and tools for securing systems which are container based.
You also need to keep five things in mind when considering using Docker for your mission-critical applications.
So, basically, there are 3 things, that we need to keep in mind when we’re using the container-based system for our applications.
Unlike kernels of virtual machines, the kernel is shared among all the hosts and container, drastically increasing the risk as whatever vulnerability exploited, will cause a cascaded compromise. So in case, a kernel is compromised, it will take down the entire host. So, in this way a VM is much better:
as an attacker would have to make its way through both VM kernel and its hypervisor before touching host kernel.
Like previously discussed all container share resources. So its possible that if If one container is able to gain self-access to certain resources–like memory and more uncommon resources such as user IDs (UID)—it can block out other containers on the host, resulting in a denial-of-service (DoS), whereby users are unable to access part or all of the system.
So in case an attacker gains access to one of the containers, we wanna make sure that none of the other containers are compromised as well. As by default, all the users aren’t namespaced, so any of the processes that come out of the container will have the same freedom and access on the host as it was able to in the container. Which means that you will also want to worry about potential attacks that escalate privileges–when a user gains privileges that are elevated like of the root user, Given that container technology is still quite new, you should ensure your security around the possibility that container breakouts are possible.