Cloud Security Issues, Threats and Concerns
The cloud migration strategy started with the idea of IT services becoming easier to deploy and cheaper compared to the traditional enablement model. Cloud computing strategies did not map into the classic IT including siloed network, storage, application, database, and operations or reporting to various managers, directors and VPs. Many companies with several business divisions and subsidiaries, the chances of redundant systems, networks, and procedures run rapidly throughout the organization. Every group having their “own” network, data center, storage, and applications became the normal IT landscape.
The idea of cloud computing benefits was not top of mind with many companies. Days of cloud computing were only seen at the government and university environments. Enterprise organizations were still stuck in legacy IT models and did not see the growing benefit of developing an enterprise cloud computing strategy.
With these redundant silo centers, the time to market, cost of development, and post deployment model became unsustainable, CIO’s and CEO’s began to mandate their departments consolidate their services by adopting a cloud first model. The first mandate was to shut down legacy data centers and controls. While this strategy seemed to make sense, the migration to the cloud became much more costly and more difficult to secure.
Many companies realized early on the legacy security controls like firewalls, IDS, and one-time passwords did not work in the cloud world. Many of their current employees also lacked the skills needed to manage an on-premise and cloud deployment at the same time. This lack of knowledge resulted in several security breaches that went unnoticed for a long period. Many companies rarely budgeted for pen testing because they believed the cloud was secure and the need to pen test was less important.
Several new security challenges rose from the migration including misconfiguring, lack of visibility, and the new of unsecured API’s and 3rd party interfaces.
Misconfiguration
Misconfigurations of cloud security settings became a leading cause of cloud data losses. Many organizations’ cloud security strategies are inadequate for protecting their cloud-based infrastructure.
Cloud infrastructure is designed to be easily usable and to enable easy data sharing, making it difficult for organizations to ensure that data is only accessible to correct parties. Companies using cloud-based infrastructure also do not have complete visibility and control over their infrastructure. Meaning that they need to rely upon security controls provided by their cloud provider like Amazon and Google to configure and secure their cloud deployments. Since many organizations lack the knowledge to secure cloud infrastructure and often have multi-cloud deployments. Pen testing became a necessity for organizations to identify misconfigurations. Companies started to map out a cadence for pen testing to stay ahead of this attack vector.
Lack of Visibility
An organization’s cloud-based did account for a new application and systems monitoring capability at the time of deployment. Many legacy tools for increasing network visibility are not effective for cloud environments, and some organizations lack cloud-focused security tools . A lack of security talent also resulted in poor system visibility.
Leveraging APIs and Interfaces
APIs and interfaces were needed in the development cycle for cloud applications. APIs are essential for customized cloud experience. They also present a threat to security. APIs allows companies to customize the cloud solution features according to their needs including encryption, access, and data recognition.
While APIs are helpful for developers, at the same time, if not scrutinized for poor design and security, can cause security risks too. Companies also lacked the proper tracking tools to monitor activity through access management consoles.
Security architecture Vulnerability
With the enablement of cloud based virtual private cloud instances, many tenants believe their new platform is far more secure and easier to manage than legacy on-premise deployments. Originally, moving to the cloud started with evolution of software as service providers offer a hosted application with several open API and global access. These SAAS providers leveraged VPCs within AWS, Google, and Azure. The responsibility of platform security and data integrity fell upon both the provider and end user. SAAS providers focused on certifications around SOC 2 compliance while end users focused on encryption, multi-factor authentication, and data in transit protection for their data security strategy. While the provider lacked the visibility of the end user’s data protection plan, the end user had to rely on the SAAS provider to maintain the SOC 2 compliance framework. This element of trust between the two parties continues to be a decision point when companies decide to leverage a SAAS application.
Architecture for a SAAS application is similar to companies developing their own services within the cloud. Both companies may develop their services with open-source code, 3rd party libraries, and orchestration to enable their capability. Each of these architecture components are all common with inherited security risks. Open source is widely used in both waterfall and agile development models. Open source is normally free from royalties. Open source allows for companies to develop their own source code from these foundational libraries. 3rd party libraries similar to open source also help in the rapid deployment model for application creation. 3rd party libraries, like node.js, are a series of packages already built by a previous developer with either a broad or specific purpose. These libraries tend to have built in API’s to hook into other applications and databases. Security frameworks deployed within the 3rd party libraries tend to be light in nature with minimal adaptive control protection. Developers love 3rd parties libraries in order to help speed up their application deployment schedules. With the adoption of the open source and 3rd party libraries for product development, the growth of orchestras also grew within developer circles. Most of all, these libraries built by others are not free from security issues, such as the Log4J vulnerabilities that were discovered in December 2021.
Automation of application creation, connection to API’s, along with on-going patching of systems all evolved the strategy for the cloud deployments. The cloud ushered in several new capabilities including remote monitoring, database replication, and containerization. These new innovations lead to greater time to market rapid deployment, greater global access for clients, along with complaining with local, regional, and GEO requirements. With the value gained by these new enablements, a comprehensive security management and control framework lagged behind. The need for rapid deployment and time to market outweigh the need for security control. Only after newly deployed systems became compromised during the initial launch did the security control mandate become a top line priority.
Cloud Security Product Overload
With cloud security becoming a critical priority, the enablement and access to several new adaptive control capabilities began to create an operational and architecture overload. Starting with the basic cloud environment and public cloud access, developers and architects relied on SSL encryption as the standard for remote access. These secure protocols used a variety of crypto keys around 128 to 2048K key sizes for better security. Soon after these connection methods were enabled, hackers used these common methods to connect into the cloud and began to develop threat vectors to increase the attack surfaces.
Evolution of CASB, MFA, and Zero Trust
Cloud security professionals knew at some point connecting to cloud application providers would require even more additional security controls. Advanced security architects knew attacks against cloud infrastructure would only increase.
One strategy that surfaced from vendors like Palo Alto, Netskope, and Proofpoint was the introduction of cloud access security broker or CASB. A CASB can offer services such as monitoring user activity, warning administrators about potentially hazardous actions, enforcing security policy compliance, and automatically preventing hacks. The CASB connection would exist between the cloud user and the platform. This new security control gave the ability for the cloud security teams to monitor user behavior under SSL connections. CASB also enabled data leakage preventage or DLP strategy to help data exfiltration attacks. Data exfiltration is one of many challenges in cloud computing. Attacks on cloud services evolved well beyond denial of service attacks. Part of the cloud adoption journey also entailed a new method of user authentication. Companies also began to enable several multi-factor authentication strategies from PING, OKTA, and Microsoft.
MFA strategies created more security control and enablement across all applications within the cloud. Many companies would require all connections to the cloud applications to originate from a MFA portal. Any attempt to log into a cloud application outside of the MFA portal, would result in a blocked connection. With the enablement of CASB and MFA, security did see a drop in successful attacks against their cloud platforms. However, in time hackers came to find ways to circumvent these adaptive controls. With this new attack surfacing, cloud apps and the benefits of cloud computing began to become more complex and costly to manage. No longer did security architects and DEVOPS teams begin to consider who to trust when allowing connections into the various cloud applications. Current cloud capabilities did support the idea behind connection proximity, granting the ability to regionalize user connections based on IP address or ping distances from DNS servers. Current cloud deployment model would require more GEO located data centers in order to better support user proximity strategies. While this strategy worked at a network connection level, cloud data security and cloud computing solutions lacked this capability at the user access level.
Zero Trust and SASE (security access service edge) strategies became a new functionality. Vendors like Cisco, Zscaler, and others enabled products that created a true edge security connection strategy well beyond simple IP address routing and connection scoring. Zero trust is built on the idea that no one is considered trusted anymore unless they are routed specific to a zero trust edge architecture prior to being allowed to connect to internal and external cloud applications. Zero trust systems would perform a variety of security controls including MFA, validate CASB controls, scan the endpoint for proper patch levels, and control exactly where these users would be allowed to connect. Zero trust continues to be rolled over by organizations in hopes of controlling user access and preventing further attack surfaces into their cloud applications.
Pen Testing – A Necessity
Did the cloud deployment make things easier and less costly? Probably not. Security teams now need pen testing more than ever before. These pen tests should be ongoing in a growing cloud environment, not done on a scheduled calendar basis. Working with trusted 3rd party providers is critical for a company’s success in the cloud.
Pen testing should include the following;
- Validation and effectiveness of the CASB deployment.
- Validate the Zero trust SASE model is secure and working.
- Validate the testing for endpoint machines connectivity prior to being allowed access to the applications in the cloud.
- Continuous pen testing to validate misconfigurations are no longer an issue
- Continuous testing on all active APIs and 3rd party interfaces
- Are the open sources libraries without the source code secure?
- Is the system automation strategy working and secure including application and container deployment?
- Execute approved pen testing against 3rd SAAS providers
- Execute approved pen testing against cloud based VPCs
With increased visibility of continuous pen testing, are the systems more secure and available to the users?
Pen testing is key in determining this matrix score.
Cloud security threats are very real. Cloud servers will continue to be under attack even under Zero trust models. Continuous pen testing and monitoring of systems will help systems stay safe.
