Security Automation: Lessons Learned from Discussions with Security Vendors

Security Automation: Lessons Learned from Discussions with Security Vendors

We are hosting a series of events around the U.S. called Integrated Technology Summits where we talk about the real-world struggles facing security leaders and how leveraging integrated security technologies yields practical solutions. We typically feature two or three of our technology vendors and discuss how these can be made to work better together, creating operational efficiencies and security effectiveness – saving time and money, while also helping to reduce risk.

The cohesive message we tell with our vendors is made possible using API and other integrations, which then allow us to do some really cool and exciting things with automation and orchestration. But before we get to that, it is important that we first understand why we want to integrate these solutions. After all, if we do not have a real need and are not solving a real problem for our organization, then this is merely an interesting exercise that may or may not actually help us reduce risk in the enterprise.


Many clients that we talk to have a visibility problem – put simply, they don’t know what they don’t know about what is happening in their environment. Many organizations have some level of visibility at the traditional perimeter thanks to firewalls or IDS, but often lack an appropriate level of fidelity at other critical junctures – at the endpoints, within the network perimeter, or into the cloud, just to name a few. In a world where the traditional network perimeter is eroding, these vantage points provide a wealth of information into assets, risks, and exposure.

Sometimes these blind spots are the result of a technology gap – the organization does not have the appropriate tools implemented to provide the level of granularity desired. In other cases, capable tools do exist in the environment, but the telemetry data that they are (or could be) collecting is not being shared with other solutions in the environment. These other solutions, such as a configuration management database or threat intelligence platform, are inadvertently rendered less-effective by virtue of having less information – knowledge is power.

Many organizations we talk to are not entirely comfortable with the idea of fully, or even partially, orchestrating security activities. They fear that something may go wrong without a human in the loop to provide a sanity check against automated actions, which could potentially disrupt business operations. Integrating technologies in the environment for the purposes of data sharing is a good way for organizations to begin exploring automation and orchestration. A sharing-only approach provides an initial value discussed above, lays the technical groundwork for additional, automated capabilities in the future, and provides an opportunity for organizations to self-evaluate whether their maturity and culture will allow more robust usage of these capabilities.

Sharing is Caring

At a recent Integrated Technology Summit in Dallas, Kudelski Security featured three of our technology partners to discuss automation and orchestration – McAfee, Aruba Networks and Illusive Networks. At first glance, these three vendors may seem to have little in common. But as we discussed with the security professionals in attendance, each has a vantage point (or perhaps multiple vantage points) and collects relevant information about the IT environment that could enhance the capability of the other tools, if only shared.

Fortunately, most vendors in today’s market embrace the heterogeneous best-of-breed ecosystem that defines many enterprises today. But, as we also discussed with the audience, platform-based security vendors leverage the capabilities of automation and orchestration, inherently, and also provide this for their customers to utilize outside of the platform. For example, although security tools can be integrated point-to-point, leveraging a common communications layer such as McAfee’s OpenDXL abstracts the exchange of information from the underlying application architecture and reduces the integration and maintenance complexity of McAfee and numerous third-party tools.

With the communication groundwork laid, organizations can begin the process of enabling data exchange. Aruba wireless access points can share telemetry data on connecting endpoints, including device information, location, and time. Illusive Networks can share high-fidelity alerts on advanced persistent threats and zero-days exploits it detects when a deployed deception is triggered. McAfee Advanced Threat Defense can share threat intelligence information from indicators of compromise (IoCs) identified through code analysis or malware sandboxing.

Beyond these use cases, the sharing possibilities of contextual data are numerous, especially as organizations consider integrating additional tools within the environment, such as directory services and other security analytics tools we may have deployed. These integrations can begin to address the blind spots they have in their environment and establish a path forward for additional integrations and orchestration opportunities to make sure our security tools can (you guessed it) work better together.

Be on the lookout for an Integrated Technology Summit soon in a city near you. Our next event will be later this fall in Austin, Texas. For a full list of Kudelski Security events, click here.

Protecting a Perimeter-Less World: a Reference Architecture for Cloud Security

Protecting a Perimeter-Less World: a Reference Architecture for Cloud Security

Do you have full visibility into your cloud applications and platforms? Are all of your cloud assets securely configured and managed? Can you contain and analyze a cloud attack in an automated way?

Cloud security is top of mind for CIOs and CISOs, faced with a changing technology paradigm in which control and security responsibility has become a shared concern. Widespread adoption of software-as-a-service (SaaS) applications and infrastructure-as-a-service (IaaS) platforms as a means of improving business efficiency naturally leads to an increase in the number and frequency of cloud-based cyber-attacks.

Organizations are challenged to transition legacy systems (and the associated legacy IT management or security practices) to newer cloud paradigms, often inadvertently and unknowingly creating security risks in the process. In order to create an integrated, holistic and workable cloud security strategy, CISOs – particularly public-sector and larger enterprises – must reexamine policies and technology choices against an ever-changing and sophisticated threat landscape.

CISOs are faced with a changing paradigm whereby security responsibility in the cloud is a shared concern between the cloud service provider and customer. With shared responsibility, organizations can leverage the security foundation and, in many cases, cloud-native security tools offered by the providers to focus their efforts on securing operating systems, applications, and data. However, customers must clearly understand what their security responsibilities are and not incorrectly assume these activities are being performed by the cloud platform or application provider.

In this second paper of our Reference Architecture series, we consider cloud security and the relevant protection technologies from some of the industry’s leading vendors.  We use the widely recognized National Institute of Standards and Technology (NIST) Cybersecurity Framework (CST) to identify these activities, and categorize them by their respective components from Secure Blueprint, our strategic approach to cybersecurity program management.

To fulfill these cloud security activities and address cloud risks, we highlight cloud protection technologies from leading vendors that work in concert with the native security services from leading IaaS and SaaS providers. We take a clean-sheet approach that presupposes no existing cloud security or management technologies. However, we recognize that most organizations do not start with a blank slate, and in some cases, alternative technologies to the ones that we have highlighted may make more sense based on current IT investments, business needs, regulatory considerations, etc. Organizations can also compare their incumbent risk management activities and technology solutions to identify gaps in their existing cloud protection.

Our aim is to help you to help you make smart technology decisions in an ever-crowded and noisy cloud security market.

To better understand your cloud risk posture and identify gaps that may exist with your current cloud protection technologies, click here to read our Cloud Security Reference Architecture.

API Security: Awareness in a Cloud-Connected World

API Security: Awareness in a Cloud-Connected World

Earlier this month, the Open Web Application Security Project (OWASP) published a release candidate for its well-known Top 10 list of the most critical web application vulnerabilities. In this first update since 2013, some vulnerabilities have been combined or dropped, making way for new entrants including under-protected Application Programming Interfaces (APIs). This update is notable because the OWASP Top 10 is an important reference for many cybersecurity compliance and regulatory standards but also highlights the shifting threat landscape for web-based applications and technologies over the last few years. While API security is not new, the responsibility for it has been largely left to the software teams developing the APIs. Awareness and concern for web API security is increasing for CISOs in the broader enterprise security market.

From SaaS to social media, APIs provide the connective tissue between systems and services in our interconnected world of mobile, cloud, and IoT applications. APIs are software programming methods, protocols, and tools that enable communication between software components. APIs have long existed for computer hardware and software, including operating systems and databases, but are perhaps more commonly associated with mobile applications and web-based systems in today’s cloud-connected world. Enterprises are now connecting disparate and non-traditional IT systems (e.g. life/safety, physical access control) through web APIs and enterprise service bus platforms to enable better and more efficient business outcomes.

Web APIs use the same underlying technology as browser-based applications, so many of the same security concerns exist that enterprises are familiar with from browser-based applications. An under-protected web API can serve as an efficient way for an attacker to exfiltrate data, using malicious programmatic requests that are much faster to execute than web browser-based methods. Web APIs that are critical to business operations may be the specific target of data integrity or DDoS attacks, disrupting critical business operations. Some APIs include file transfer capabilities that can be a vector to introduce malware to a network. However, since web APIs are not relegated to web browsers, the attack surface is varied and may go undetected if organizations are not adequately monitoring web API activity across the enterprise. So what can CISOs do to shore up defenses for the web APIs in their environment?

  1. Asset Management – As with other areas of cybersecurity, you need to know what assets (APIs) are in your organization and also understand their function and security capabilities. This can be no small task since web APIs exist for both hardware and software, including on premise or cloud-hosted software applications (especially unsanctioned SaaS applications of Shadow IT). And you cannot just look at traditional enterprise IT assets – badge systems, embedded ICS controllers, and IoT devices use APIs to function or integrate with other systems. Aside from reviewing the API documentation of sanctioned systems, an application-aware firewall or cloud access security broker (CASB) can help identify previously unknown APIs, and the associated software application, unmanaged IoT device, etc.
  1. Secure communication – Using properly-implemented TLS encryption for communication between API endpoints can provide confidentiality and integrity for the data in transit, preventing data sniffing or manipulation from man-in-the-middle attacks. If you want to inspect the API traffic, using TLS will require decryption/encryption capabilities similar to what you may already use for a web proxy. Also remember that care must still be taken to securely store sensitive data (e.g. credit card numbers) after it is transmitted using web APIs.
  1. Strong authentication and authorization schemes – CISOs will need to work closely with API developers or vendors to understand what authentication and authorization schemes are supported. Authentication will validate the identity of the application or service requesting access to the API; use strong authentication, such as API tokens, instead of basic authentication (i.e. usernames and passwords in the HTTP authorization header). An authorization framework like the token-based OAuth 2.0 standard enables limiting applications or services to only a certain sub-set of API methods and data.
  1. Segmentation – Limit the accessibility of your APIs to known and trusted endpoints using an API gateway or firewall network segmentation. These options may not always be operationally feasible and can introduce availability or scalability concerns in certain scenarios or topologies. However, these control points can serve as a mitigation for legacy APIs in your environment that do not support strong encryption, authentication, or authorization schemes.
  1. Attack Detection and Prevention – Implement protections to detect and protect against API attacks. CASBs, web application firewalls (WAFs), and application-aware firewalls can help to detect and prevent API-based attacks. However, because each web API can have a unique syntax, data structure, set of methods, etc., these tools can only be so effective without specific understanding of the APIs in your environment. For example, CASBs may include specific logic for APIs from leading SaaS applications and can be effective in identifying malicious activity or data exfiltration for those applications. Web application firewalls (WAF) may protect against certain common web-based attacks that are launched against APIs, such as code injection or malformed requests, using WAF protection rules or API rate limiting. Anti-malware systems can detect malware in files that are embedded in an API call.

API security begins with good software development practices – many of the other OWASP Top 10 recommendations are also applicable to developing secure web APIs. Including under-protected APIs as a distinct threat in the latest OWASP Top 10 release candidate highlights the growing concern of API-based attacks. Traditionally the purview of software developers, web API security is becoming a greater consideration in enterprise security. CISOs now find themselves defending a growing and more diverse IT environment, which includes more cloud-based applications and IoT devices as well as enterprise-level application integrations. Web APIs present an amazing opportunity for business and IT extensibility, efficiency, integration… and mischief.



Protecting the expanding perimeter: a Reference Architecture for Endpoint Security

Do you have full visibility on your endpoints?  Are all your endpoints securely configured and managed, even when off the corporate network?  Can you contain and analyze an endpoint attack, regardless of where the endpoint is?

As numbers of remote workers increase, enterprise networks become more interconnected, and as visibility on the network shrinks, the end user and their endpoints have become the growing focus of advanced attacks.

Every CISO has experienced the unique challenges of endpoint security – of selecting technologies that best match business needs and deliver effective defense.  In order to adapt an integrated, holistic and workable endpoint management strategy, CISOs – particularly of larger enterprises and public sector organizations – must reexamine policies and technology choices against an ever-changing and sophisticated threat landscape.

In this first paper of our Reference Architecture series, we consider endpoint security and the relevant protection technologies from some of the industry’s leading vendors.  We use the widely recognized National Institute of Standards and Technology (NIST) Cybersecurity Framework (CST) to identify these activities, and categorize them by their respective components from Secure Blueprint, our strategic approach to cybersecurity program management. We base our analysis of the solutions on our real-world experience in deploying, integrating and managing these technologies.

Our aim is to help you to help you make smart technology decisions in an ever-crowded and noisy endpoint security market.

To better understand your endpoint risk posture and identify gaps that may exist with your current endpoint protection technologies, click here to read our Endpoint Reference Architecture.