Visibility in application and cloud security is ripe for innovation

Better information leads to better decision-making. That’s not a particularly bold statement. But at the same time, we have a tendency to look for data in our narrow area and then … just more of it. More fields. More reports. More dashboards. We don’t often take the opportunity to step back and re-evaluate what you’d actually need to make smarter decisions. Asking “How can I gain complete risk visibility into my applications and infrastructure?” is not a simple question and it deserves more than a simple answer.

There is room for significant innovation in application and cloud visibility and it’s time for security practitioners to demand more.

CISOs, Security Architects, Engineering VPs and managers all want to understand their applications better, including code components, security controls, data, and their business impact. This is easier said than done.

DevOps has empowered developers to take more initiative and be more creative than ever. The downside of that flexibility is that it’s harder to enforce consistency across multiple independent teams, from coding standards to processes, procedures, and technologies. When building a microservice, a development team will naturally gravitate towards the best tools for the job at hand, rather than thinking about long-term impacts across multiple teams. But the pressure developers face to deliver faster has consequences.

Technology sprawl has a long-term strategic impact. Development, security, and legal teams need to keep up with the latest security and compliance issues across frameworks and languages. Using more than one technology for key management, authentication, authorization, and encryption leads to unnecessary fragmentation in adjacent areas as well. Visibility into all of your code components is absolutely essential and required to understand your risk, but there’s more to the equation.

Understanding the code itself is essential, but unfortunately, that’s usually where the thinking stops. To have a true business-level impact on application and cloud security, we need to expand beyond technologies and code because risk is multi-dimensional. Understanding the individual developers working on a feature can be the key to making better decisions. The same is true for data in ticketing systems, Pull Request discussions, and cloud configurations.

True application risk visibility requires clarity from end-to-end; from design to code to cloud. Data from all stages can help make better decisions early in the development process, improving security and reducing unnecessary rework.

Also consider how greater visibility into your developers’ expertise can help improve both the security and efficiency of your development process. When a risky material change is discovered, it’s essential to find the best person to investigate and remediate the issue. You need to understand which developers have experience in specific technologies, languages, security controls, and even specific types of features. On top of that you need to understand the roles of other contributors, including QA, DevOps, Product Management, etc. and how they contribute to the application. In other words, to find the right person for the job, you need to know the person and the team as well as the job! “Asking around” is not an acceptable – or scalable – solution.

In addition, many organizations are building a Security Champions Program, where knowledgeable security experts are embedded into each development team. A deep-understanding of your developers’ strengths and weaknesses is critical to the success of the program. Your Security Champions should have a skill set that fits with their teams so they can provide the right coaching to the right people. They can also better understand when their expertise is required.

So yes, data-driven decisions are better decisions. But don’t limit yourself to what’s in front of you. There is tremendous potential to improve our understanding of both our code and the context that surrounds it. Demand more.