By Kunal Modasiya, Vice President, Product and Growth, Qualys
Technology does not stand still. There are new platforms and services entering the market every day, and enterprise architects have to understand how they can use these new and emerging technologies alongside tried and trusted solutions that have been in place for years. Managing all this infrastructure to get the most out of your investment is one thing, but how can you protect all those components against risk as well, especially web applications and application programming interfaces (APIs) exposed to the internet?
Having multiple platforms in place is common. According to the Cloud Industry Forum, 55 percent of companies have a hybrid cloud strategy in place, while 95 percent of all companies use some form of cloud service. The Cloud Native Computing Foundation found that 84 percent of companies are using or evaluating Kubernetes, with 58 percent running Kubernetes in production. Across the cloud providers, adoption of serverless computing is growing too, with more than 70 percent of companies running on AWS using serverless according to Datadog.
What does all this growth in new platforms mean for security teams that are tasked with keeping all these deployments safe? How can they keep track of what is changing in these applications and infrastructure when the containers and serverless workloads may only exist for minutes at a time? And how can the teams involved across the business work together more effectively? It’s important to note here that APIs make up 83% of the attack surface for web applications and 29% of overall web attacks targeted APIs in 2023.
Understanding all your risk
For IT architects and security teams, the joint challenge here is actually one of the oldest ones in IT – knowing what you have. Getting an accurate inventory of all your software assets and components is a hard task on one platform, let alone across internal datacenter deployments, web applications, public cloud implementations and modern cloud-native applications. Keeping this inventory up to date is harder still, given how much change will take place over time across the entire application estate.
Alongside this inventory, there are other factors to consider. Not all applications are created equal, and an issue in an internal web application that is used by a few people every month will not be as important as a critical vulnerability in a business application that is responsible for generating revenue every day. Yet both of these applications may have a flaw, and alerts sent to request fixes or updates get made.
Internal processes and workflows will also affect the situation. While security teams might spot potential issues in an application or software component like an API, they will not be responsible for making the change themselves. That will fall on the development or IT support teams responsible for that application. However, not every company maintains accurate lists of who is responsible for the code or software components in those services, while there may also be business owners for those applications that also have to be consulted. APIs themselves are also targeted for attack, as they are the critical glue that binds applications and services together.
Prioritising security across teams and processes
To keep this infrastructure secure over time, security teams look out for potential attacks on applications. This might be through vulnerabilities in software components, misconfigurations in the services or platforms themselves, or issues with access control where stolen accounts might be used. When any issue is detected, alerts will be sent to the security team and they will then evaluate the risk involved.
This evaluation then triggers alerts to the developers and IT operations teams for action. However, the sheer number of software issues, faults and flaws causes problems. How do developers know what to work on without the right context? For enterprise architects, how can they understand the impact that any changes might have on wider service delivery? For the business, what is the risk of making a change and – more importantly – what is the risk if you don’t?
To answer this, the teams involved need to understand the priorities that the business has around security and how much risk the business faces. Getting this information to application teams will help them see where they must concentrate efforts to stop attacks and cut out risk, and equally where issues can enter the backlog of work to be completed in due course.
To make these priorities clearer to everyone, one must look at risk from a business context, rather than analysing each platform’s issues on its own. For example, should you look at issues around your APIs against each other, or instead evaluate your critical API attacks alongside similar level risks around misconfiguration or vulnerability in the cloud, or within software container images? By focusing on the highest priority issues that represent the most risk to the business, you can concentrate your resources and efforts on preventing attacks from succeeding.
This prioritisation has another benefit – it provides other teams with insight into the issues that they need to address first, and where they may need to manage their workloads differently to mitigate potential problems while patching or updates are tested. Where these workloads cross over between teams or deployments, this prioritisation can help everyone pull in the same direction, rather than pointing fingers back and forth around those updates and who is responsible.
Most importantly, this kind of risk information can be provided to the board and leadership team so they can understand how the IT function is handling potential risk over time. While you might not expect your board to understand the subtleties of CVSS scoring or cloud deployments, they will understand risk in context. Building up this understanding is an essential task for CISOs, but it can deliver the support you need for collaboration and resources when issues are serious. It can also help remove roadblocks and competition between teams that might slow down high priority work to patch issues.
Improving processes, removing issues early
While this approach to risk management can remove problems that come up in software or cloud deployments, it is not enough on its own. Alongside the reactive side of vulnerability management, security teams can help developers to improve their processes to prevent more security problems getting into the software development life cycle process in the first place.
This approach is normally viewed with suspicion by developers. After all, security teams often don’t write code themselves, and they have very different goals and metrics to software teams. So how could they help improve software development, and why should I use their tools? This all sounds like additional overhead for developers with very little in the way of upside. However, this should not be the case.
Integrating security into the developer workflow is possible. For example, rather than insisting that developers use security tools, why not call on security insights through APIs built into the CI/CD pipeline tools that developers already use every day? This keeps developers in the environment and workflow that they are used to, while still getting them the information they need. Alongside this, developers can get more support on following best practices for their applications or APIs, such as automatic checking that the likes of OWASP’s Top Ten for web application security practices have been followed. Getting these recommendations earlier in the development process makes it easier for developers to fix them, rather than being provided with a long list of issues to fix in production.
Whatever platforms you run, you will run into problems with security updates or vulnerabilities that have to be patched. Getting this data alone is not enough – instead, you should look for more recommendations on what to prioritise and what the most pressi
ng risks are. With this information, you can also get guidance on what to fix, and who to speak to in order to make that process easier from a software perspective, and from a business one as well. The overall goal for software is to deliver what the business needs, and security and enterprise teams want to keep that delivery process running as smoothly and as securely as possible. Getting that information in the right fashion, so everyone can prioritise and understand risk, turns that from an ideal into reality.
Kunal is currently VP of Product Management for the CyberSecurity Asset Attack Surface Management (CAASM), Web App and API Security product line at Qualys, as well as previously working for the company to incubate its XDR product line from inception. Kunal has spent 15+ years working at startups, and big and mid-size companies in cybersecurity, networking, and application security in both product and engineering roles. He has experience at Juniper Networks, Extreme Networks, Sun Microsystems and Infinera. Prior to re-joining Qualys, Kunal was heading products at an Israeli startup in API security and bot management in the application security space.