Cybersecurity organizations should partner with business units to create a shared and flexible cloud governance model that better enables responsible cloud adoption.
Businesses cannot (and often will not) wait for security organizations to create inflexible governance frameworks for cloud adoption. After all, the cloud is supposed to be flexible and business-enabling. The high-speed transformation to remote work and the rapid increase in cloud workloads due to COVID-19 highlights that technical agility is key to both enabling business outcomes and surviving times of crisis. In recent months, software-as-a-service (SaaS) collaboration platforms, such as Zoom, have seen a spike in usage, and 59 percent of enterprise respondents to a recent survey by Flexera plan to accelerate cloud adoption because of the pandemic.
However, organizations must still protect their data, preserve user privacy, manage technology costs, and ensure business continuity. In some respects, these demands are even more important during uncertain times. A shaky financial climate increases pressure to control costs; a shift to remote work reshapes the cyber threat profile for the organization. Businesses need to control financial, operational, and security risks when facing the realities of a pandemic.
Accelerated Cloud Adoption in the Age of COVID-19: Why is Cloud Governance Important?
Many stakeholders are concerned with a variety of governance topics, mainly those that focus on the cloud. Cloud governance is a multi-disciplinary approach that ensures cloud resources are designed, delivered, and consumed in a manner that adequately addresses organizational risk. However, organizations face an increasing challenge since execution is usually siloed and often driven by different internal motivations.
Different groups use different tools, techniques, and taxonomy to address their respective needs. Without a coordinated effort, this creates redundant work for the business and undue overhead for cloud consumption. Isolated governance also creates spotty coverage of the various technical and non-technical risks that organizations should address.
Many business units within an organization care about governance:
- Cybersecurity teams care about security governance, ensuring that resources and cloud environments are compliant with regulatory or corporate policies and best practices
- Accounting cares about cost governance, ensuring that OPEX costs can be adequately controlled, tracked, and assigned to the right budgets
- IT and DevOps groups care about operational governance, ensuring that resources are deployed consistently and follow operational best practices
Cloud governance is key to realizing the benefits that cloud offers, including agility and elasticity, while minimizing unintended business or technical risks. However, risks are not limited to any one domain — cybersecurity, financial, or operational — and should be addressed collectively and holistically.
Cloud governance must be robust and adaptable to meet rapidly shifting business demands, not only in cybersecurity. As organizations continue to transform how they conduct business, there is a unique opportunity for cybersecurity stakeholders to take the lead in bringing together their peers from other parts of the business.
Security is often the primary driver for the governance of cloud adoption, so it is logical to have this group lead the charge to build consensus on the topic. A coordinated effort creates efficiency and consistency for these activities, reducing the redundant burden of siloed governance. A consolidated voice also lends credence to the notion that unfettered cloud usage in the name of business agility can ultimately be bad for business.
Guardrails vs. Handcuffs: Defining Flexibility in Cloud Governance
Building consensus for a multi-disciplinary cloud governance approach is necessary but not sufficient to enable business outcomes. A unified governance coalition could simply demand inflexible and prescriptive controls and processes that are incongruent with cloud agility. Just as important is how these teams choose to mitigate the various cloud risks for the organization.
Developing solutions “at the speed of business” requires a more flexible approach. It is important to squarely address the skepticism that additional oversight will create inefficiencies and delays for the business. Dictating strict controls inhibits the agility and creativity of teams. Inevitably, they will seek (and find) a way around the perceived roadblocks. Rather, putting up looser “guardrails” in the cloud enables teams to operate with more freedom, but still within parameters.
This model can provide a nice balance between constricted control and unfettered flexibility. These guardrails can take many forms but are often technical requirements implemented within a cloud platform (e.g., Azure Policy), manifesting well-written cloud security guidelines.
What Does Flexible Governance Look Like?
All major cloud platforms have the concept of tagging — metadata in the form of key-value pairs that can be associated with cloud resources. A cloud policy requires that all cloud compute resources (e.g., servers, containers) include tags for the internal cost center and the deployment environment (e.g., development, staging, production).
We can then configure the cloud platform to enforce this tagging policy for us, ensuring that the teams responsible for deployment will always provide the requisite information — a fairly low friction demand that provides value for different governance stakeholders. For example, accounting can accurately assign the costs to its department, operations can assign the requisite monitoring and service-level agreements for a production workload, and cybersecurity could have contextual information that can be useful in appropriately prioritizing a security incident or vulnerability remediation for different resources.
A Journey, Not a Destination
Following these ideas, organizations should be able to build a shared vision for cloud governance that effectively balances business flexibility with risk mitigation. They can continue to create more sophisticated tagging examples and implement governance-as-code, authoring and managing technical cloud controls like a software development project. They could even envision how this model could effectively govern the democratization of technology, through low-code and no-code development platforms.
The real test for this model is how it can evolve and adapt to change in the organization — as change has most likely already happened.
This article was originally published in Dataversity.
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.
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.
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?
- 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.
- 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.
- 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.
- 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.
- 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.
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.