Cloud Security for Developers, Part 3
I explained the need for cloud security governance in my first post. In my second post, I explained security skills involved in prevention, detection, and management of security incidents. What role do developers play in cybersecurity?
As developers, the controls implemented by security teams may seem draconian and designed to stop you from getting things done or doing your job. You can’t build as fast. These controls seem pointless because you can’t see why they exist.
I’ve been there and felt the pain of a lengthy review process in which some of the requirements and delays seemed unnecessary. Sometimes they are! But often, they serve a purpose that may not be clear without fully understanding the details that drive their existence.
One of the issues is that the problems security people are trying to solve do not manifest themselves in the same way as problems and solutions developers address. When a developer builds something, the result is something you can see and use. When a security person implements a control, it is to protect an organization from something they can’t see today (hopefully). They are looking into the future, evaluating threats, and preventing things that may happen if the controls are not in place.
Security people base their decisions on constant analysis of the risks to the environment. This analysis takes time, and sometimes years of training to understand the threats and malware that can impact systems at very low levels with intricate changes to software to evade defenses. Each new system or feature you introduce is a new attack vector that must be understood and addressed.
Some people have more or less capacity or patience to look at future outcomes, risks, and potential threats. Some want immediate gratification. I want to release this system now! That is a very different viewpoint and objective than one that wants to prevent a future threat. It is perhaps hard to maintain both mindsets at the same time effectively, but this needs to be our goal.
Balancing these two objectives and viewpoints will help prevent data breaches, while at the same time enabling organizations to release software as quickly as possible. This may be a shift in thinking for some software developers.
On the other hand, security professionals may not always understand the developer or business mindset. Although a security breach has a potential cost, so does the inability to release new products and services in a timely manner. That is where disparate teams need to come together and understand each other more effectively, and is something 2nd Sight Lab tries to help organizations do through services we offer. A team that learns cloud security together with members of diverse groups across an organization can discuss solutions to problems that help meet business, security, and software development objectives.
One of the critical points developers need to understand is that security is not a one-time implementation of a specific set of security controls. It is not just about their application alone, but the overall risk the organization faces. The security team will generally be handling the considerations of the organization as a whole and security monitoring. For your part, try to understand as much as you can about application security and cloud security controls you implement and the security decisions you make. Read the guidance and security best practices from your cloud provider for any service you use on a cloud platform. Follow application security best practices such as the OWASP Top 10, which is a good place to start. Taking a class on cloud or application security (or both) can be helpful as well.
Understand that threats exist at many different levels in a system, from the application to the operating system down to individual network packets. Attackers can exploit many layers, including API calls, containers, and cloud infrastructure, administrative interfaces, network devices, and protocols, to name a few. Work with your security team from the beginning of your project to design a secure solution that considers all the threat vectors. Your security team may walk you through a threat modeling process to determine what flaws may exist in the system. If you have a startup or small company and cannot afford a full time security person, consider an external security assessment or penetration test.
I doubt most developers want to spend their entire day looking at logs or dealing with compliance audits, risk assessments, and related paperwork. You want to build things! Appreciate the fact that the security team handles those things you may find less than exciting. Understand the bigger picture and the consequences if your organization faces a data breach. Be aware that handling security incidents in large organizations that happen anytime, day or night can be very stressful. Understand that the team testing your application for security vulnerabilities is there to keep your organization out of the headlines. Rather than fight with the security team to release your project faster, incorporate time to fix security vulnerabilities and implement security controls into your project timeline at the start.
Security automation is one of the biggest ways developers can help the security team. I am a huge proponent of security automation and explain how to use it effectively in my book on Cybersecurity for Executives in the Age of Cloud. Repeated events that have consistent inputs and outputs may be automated away to save time and money. Developers can help alleviate some of the pressure on the security team by ensuring repeated security issues are prevented before they occur. They may also be able to implement security monitoring that makes the security team’s job easier or help implement automated incident response. DevOps teams can implement automated governance and reports that offer metrics to understand the cyber risk within your organization.
Developers may believe they can automate away all security problems. However, as new attacks arise, these automated approaches are bypassed and need to be adjusted to handle new threats. Various scanners and tools capture certain types of vulnerabilities and problems, but some things require manual analysis. I face this challenge when I try to leverage as much automation as possible when pentesting, but often find issues that these automated tools don’t see. Some scanners create a large number of false positives that need to be analyzed to determine if they are indeed a threat or not. Many security incidents still require manual analysis to determine if it is a real incident, a system configuration problem, or user error. Automation is powerful, but does not completely eliminate the need for cybersecurity professionals.
My biggest advice about cloud security for developers is to learn as much as you can concerning any security decisions you influence within your organization. Try to architect and build your systems in ways that reduce the chances a data breach will occur as a result of vulnerabilities in the systems you deploy. At the same time, avoid underestimating what your security team knows or their job.
That goes both ways.
Security teams can leverage the skills of developers to automate and improve security outcomes. The two groups working together will produce the best results. Leveraging proper security controls, DevOps, and security automation will help bring down those breach statistics I wrote about in the first part of this series.
Software developers play a big part in making that happen. By partnering with your security team, who has in-depth knowledge of how malware and data breaches occur, you can help implement technology to reduce cybersecurity risk within your organization.