February 5, 2014 | Leave a Comment
January 28, 2014 | Leave a Comment
By Krishna Narayanaswamy, Chief Scientist at Netskope
On average, there are 397 cloud apps running in enterprises today. This is one of the findings in the second quarterly Netskope Cloud Report, an account of trends on cloud app adoption and usage. What makes this number interesting is that it’s about 10x the number that IT professionals estimate. Adding to the intrigue, 77 percent of those apps aren’t enterprise-ready based on the Netskope Cloud Confidence IndexTM, an objective measure of cloud apps’ security, auditability, and business continuity adapted from Cloud Security Alliance guidance.
The thing that really strikes us is the average number of cloud apps per category in each enterprise. The largest number is Marketing, with 51. That’s not that surprising, though. Our own startup marketing department uses almost that many apps. The second highest was more concerning, though: HR, with 35. While HR is a broad category, with specific apps for benefits, salary, performance, time-tracking, and more, the number still raises security and compliance questions. With that many apps, IT professionals are concerned about whether they have the appropriate controls in place to protect sensitive data like personally-identifiable information.
Beyond the apps themselves, where the real risks lie is in the usage of cloud apps. The report tracks the most common activities in cloud apps – edit, view, download, post, and share. These activities are especially telling when juxtaposed against policy violations, activities concerning data classified as “sensitive” or “confidential,” and data leakage incidents.
Get the full Netskope cloud report here.
January 23, 2014 | Leave a Comment
By Sanjay Beri, Founder and CEO, Netskope
In today’s cloud-dominated business world, it is difficult for IT departments to get a hold of exactly where their data lies and who has access to it. Enterprise security is and will continue to be a big concern because of this, but a “zero trust” policy when it comes to cloud apps is not the answer. Cloud apps like Dropbox, Salesforce and Google Apps are used for business-critical functions and can’t simply be blocked because there isn’t enough information for IT decision makers to feel comfortable.
So how do you support cloud app usage while protecting the business? Below are six key considerations to keep in mind as you create or modify existing policies to protect your assets, keep the business running and employees smiling.
1. Accept. According to a survey from OneLogin and flyingpenguin, 78 percent of organizations anticipate cloud app usage will continue to grow internally, yet 71 percent of employees admit to using unsanctioned apps. Acknowledge that cloud apps will be used whether you implement a policy or not, so you may as well have some visibility and control over it. Your employees are using these apps to be more productive by working in smarter ways; they may not be aware that their actions could cause harm to the business.
2. Learn. Get insight into the cloud apps your workforce is using and which apps are exposing your corporate data. This way, you can see where your data is going and where your business is most vulnerable. You can also identify where the majority lies as well as redundant apps with the same use cases. For example, you may find that employees are using five different CRM apps even though the company is officially standardized on one. By understanding where duplication lies, you can save money by eliminating duplicative apps from your stack.
The information required for this learning can be found through technical tools as well as good old-fashioned techniques like talking to employees and finding out what they like and want to use. Deeper learning should really look and feel more like an assessment –- or dare I say audit –- of the cloud apps being used. There are technical tools that can help, and the good news for IT is that new tools have come onto the scene that go beyond one-off or do-it-yourself firewall/proxy log data analysis.
3. Educate. More often than not, employees don’t want to cause harm to the organization they work for. Often two cases emerge: people are using apps in an insecure way or they are using apps that aren’t up to your standards of security to begin with. According to the 2013 Verizon Data Breach Investigations Report, 14 percent of data breaches are a result of employee error, and 71 percent of attacks we committed via user devices. Furthermore, over 30 percent of cloud apps are rated low or poor, according to Netskope’s Cloud Confidence Index, an independent evaluation of cloud apps based on 30+ criteria measuring those apps on security, audibility and business continuity. Most of the time employees are completely unaware that they’re putting the business at risk — and so are you. Once you’re aware of the apps they’re using, and the way they’re using them, you can begin to provide guidance on safe usage, and begin to set policies on the apps that are being used to keep the business safe.
4. Prioritize. With new apps emerging every day, it’s overwhelming to keep up, and track every single one. Start by prioritizing your policy according to the apps that are most popular among your users. Encourage app usage that is both productive and safe according to your policy. In most cases, you’ll be empowering employees to continue using their favorite apps in a safer, more responsible way. Alternatively, this is an opportunity to introduce them to new apps with similar capabilities that are more in line with the company’s policy.
You should also prioritize the security and compliance issues that are most important to your business as you begin to create your policy. Make a list of the features that all sanctioned cloud apps must have. Some questions to start with are:
- Does the cloud app include access control options (i.e., multifactor authentication or IP filtering)?
- Are the cloud app’s data centers dispersed geographically? Are they SOC-1 certified?
- Does the cloud app backup data to a separate location?
- Is customer data separated in the cloud app or is it comingled?
- Does the cloud app offer granular user policy and permissions based on the role of the user or admin?
- Does the cloud app provider offer audit logs for admin, user or data access?
- Does the cloud app have the necessary compliance certifications (i.e., HIPAA, PCI, SP800-53, GAPP, Truste, etc.)?
5. Re-think blocking. Blocking usage of SaaS/cloud apps just isn’t realistic today, and having a posture that is more focused on allowing those apps will go a long way when it comes to employee acceptance and their willingness to play by the rules. If they see the sophistication in your approach, you’ll get more buy-in when you have to block something because they’ll know it’s for a good reason.
The most important concept here is to help employees understand how they can keep using the apps they love AND help keep business data safe. These considerations will enable you to secure company assets and arm your users with the best available tools.
January 22, 2014 | Leave a Comment
SecureCloud 2014 is just around the corner and the CSA is pleased to announce the keynote speaker lineup for this must-attend event, which is taking place in Amsterdam on April 1-2.
This year’s event will feature keynote addresses from the following five security experts on a wide range of cloud security topics:
- Prof. Dr. Udo Helmbrecht, executive director of the European Network and Information Security Agency (ENISA) will speak on the uptake of Cloud computing in Europe and how ENISA supports Cloud Security in the Member States.
- Prof. Dr. Reinhard Posch, CIO for the Austrian Federal Government will present on the European Cloud Partnership and Austrian Government approach to cloud
- Alan Boehme, Chief of Enterprise Architecture for The Coca-Cola Company will present on the CSA Software Defined Perimeter initiative
- Jim Reavis, CEO of the Cloud Security Alliance will discuss trends and innovation in cloud security and CSA activities in 2014
- Richard Mogull, CEO of Securosis will give the closing keynote on Automation & DevOps
If you haven’t already registered, early bird discount pricing is being offered through February 14. Registration information can be found at:
We look forward to seeing all of you in Amsterdam in the Spring!
January 15, 2014 | Leave a Comment
Last month I co-presented a webinar with ISIGHT Partners, a leader in cyber-threat intelligence, to discuss a white paper that exposes how keys and certificates can be used for nefarious intentions. Our purpose was to highlight some of the tactics malicious actors use and outline their profiles in relation to keys and certificates. Due to time constraints, we did not cover how most organizations expose themselves to cryptographic vulnerabilities simply because keys and certificates are viewed as an operational problem and not as a security issue that needs to be addressed immediately!
For example, for most organizations today, the most critical element of certificate management is monitoring the validity period—that is, the certificate’s expiration date. The reason is simple: if a certificate expires, it will result in a service outage. Most organizations track validity periods either in a spreadsheet or a portal such as SharePoint. Disappointingly, there are many public examples of failure to manage even the expiration date of certificates—such as the Microsoft Azure outage earlier this year—let alone the actual security configuration of a certificate.
Secure Shell (SSH) keys, on the other hand, do not have expiration dates that organizations must track. Instead organizations need to have a clear understanding of where SSH private keys are stored and control the systems to which certain individuals have access. In most organizations, it is up to the application administrator or SSH administrator to track this information. Unfortunately, in most organizations, numerous individuals manage the keys, using disparate management practices, and no one can determine how SSH keys are being used in the network.
Take for example how Edward Snowden breached the National Security Agency (NSA) as an illustration of the SSH key management shortfall at the NSA.
Encryption keys and digital certificates provide the backbone of trust across corporate networks and the Internet. In planning for future expansion, organizations need to understand and appreciate that the digital universe is expanding at an alarming rate. If organizations can’t perform rudimentary key management today, how will they cope with both the volume of keys and certificates as more are consumed, and how will they secure and protect them?
This is exactly why malicious actors are increasingly taking advantage of keys and certificates as an attack vector, making them the perfect trust threat. For example, malicious actors can:
- Sign malicious code with a stolen legitimate certificate to avoid anti-virus detection
- Take advantage of inadequate procedures for issuing certificates and obtain a fake Secure Sockets Layer (SSL) certificate, which can be used in man-in-the-middle attacks
- Exploit an organization’s limited visibility into the usage of SSH to launch insider threats
- Use advances in technology to exploit legacy cryptographic technology and standards
Organizations need to stop viewing keys and certificates as a basic operational issue and start understanding that they can be a serious threat to their business if they are not secured and protected.
The question is, what do organizations do about the fact that they require keys and certificates to establish trust, but malicious actors are exploiting that trust and using it against them? There is light at the end of tunnel; organizations can still use keys and certificates to establish the trust they need in the digital world, but they don’t need to accept that keys and certificates will be used against them. That’s not to say it will never happen because chances are most organizations have already been compromised, but there are ways to limit key and certificate threat exposure and respond and remediate quickly if an organization is compromised.
Taking the first step
When it comes to key and certificate security, organizations must know their key and certificate inventory. They must also understand key and certificate attributes and make sure they are configured to meet recommended security guidelines while not impeding business goals. To do this, organizations need to scan their enterprise networks on a regular basis to address key areas:
- Secure configuration of cryptographic assets
- Detection of anomalous key and certificate usage—malicious or negligent
Secure configuration of cryptographic assets
When organizations configure cryptographic keys and digital certificates, they should follow best practice guidelines that factor in known exploits and improvements in technology. Organizations can consult standards bodies such as the National Institute of Standards and Technology (NIST), which provide recommendations for cryptographic resources. For example, NIST has established a minimum key size of 2048 bits, stating that 1024-bit keys should no longer be used after December 31, 2013. The hashingalgorithm SHA-1 has suffered the same fate<.
By enforcing standards that meet minimum security requirements, organizations can protect their network resources against potential exploits such as the BEAST exploit. However, organizations should keep in mind that evaluating singular attributes on their own will not adequately protect their network resources against breaches. As an example, when evaluating an IT infrastructure’s weakness against the BEAST exploit, organizations need to take into consideration the version of Transport Layer Security (TLS), the cypher suite, and the configuration used. Evaluating each of these factors individually would not bring to light the vulnerability.
Detection of anomalous key and certificate usage
Simply identifying the key and certificate inventory will not help organizations detect rogue usage of an SSH key or malware that is using a self-signed certificate to encrypt command and control (C2) traffic. To detect these issues, organizations need to understand the key and certificate inventory and the policies being enforced—all of which were addressed in the first step. Organizations must then frequently scan the environment so that they can detect any rogue keys or certificates that may have been maliciously placed in the network. If a rogue key or certificate is detected, organizations can investigate how it is being used and take action.
As the use of keys and certificate as an attack vector continues to rise, organizations need to take responsibility in securing and protecting the very trust that is established by keys and certificates. Treating them as an operational issue will only result in opportunity for malicious actors to compromise networks. Regularly evaluating the network to detect key and certificate vulnerabilities is the only way to mitigate key and certificate based attacks.
January 15, 2014 | Leave a Comment
Steve Malmskog has more than 15 years of experience as a chief network architect.
For more Movie Line Monday videos by Netskope, the cloud app analytics and policy company, feel free to visit http://www.netskope.com/
January 9, 2014 | Leave a Comment
We have entered the age of pervasive connectivity. Regardless of whether we are at home, in the office, or on the road, most of us are almost always connected. This trend is blurring the lines between work time and leisure time, with the same devices used for both contexts interchangeably. To support this new connected world, organizations are turning to the cloud – where technology services are consumed as needed, and the associated data can be stored anywhere – or they face being left behind by customers and competitors.
While this “always on” connected world utilizing cloud services brings tremendous opportunities, including tighter collaboration, increased business innovation and accelerated productivity, it also brings significant change from the constraints of client/server and first generation Web applications. It requires organizations to re-evaluate their IT and IT security policies, procedures and processes. The increasing complexity of IT infrastructures and the massive adoption of cloud-based IT services demand a new approach to IT security and compliance that ensures the security of traditional enterprise-based IT solutions along with newer cloud based IT services.
Along with these technology changes, organizations also face a dynamic threat landscape. Cyber attacks are targeting new layers of the IT infrastructure. In addition to well-known (but too often ignored) vulnerabilities and methods of attack, the proliferation of networked devices, endpoints and web applications provides attackers with an expanded target area of vulnerabilities to exploit across diverse IT infrastructures. For example, according to an ENISA 2012 survey, a top threat is malicious HTML code injection into websites that exploits vulnerabilities in user web browsers (also known as drive-by download attacks), and trends indicate that this is an area of increasing risk.
In response to these challenges and to reduce the IT infrastructure on premise, many organizations are turning to cloud-based security solutions. Cloud-based security services are having a significant impact on the existing information security market, influencing the way security controls are deployed and consumed, and driving changes in the market landscape, particularly around a number of key security technology areas including secure email gateways, secure web gateways, vulnerability management, log/event management, web application firewalls, and identity and access management.
Traditional IT security and compliance approaches often struggle to effectively secure evolving IT environments. As IT infrastructures evolve to a mixture of on-premise, cloud and hybrid environments consisting of multiple networks and increasing numbers of devices, traditional on-premise enterprise software products may limit the ability of organizations to effectively protect their infrastructures from security threats and ensure compliance with internal policies and external regulations. Cloud based security services are designed to secure all types of IT environments, including a mixture of enterprise, on premises IT with cloud based IT.
But just as with other cloud based services, organizations considering the use of cloud based security services must ensure they can evaluate the service providers and understand the risks of using a third party service provider. Organizations continue to grow and mature their vendor/third party risk management programs, and they are improving their abilities to assess, understand and manage the risk of engaging third party service providers, including cloud based security solutions. These programs enable organizations to make informed, risk based decisions about adopting cloud services which will likely lead to even greater adoption rates of all types of cloud services, including cloud security services. Of all the cloud service providers, the cloud based security service providers often understand organizational needs and requirements for third party risk management as well, if not better than other providers.
In tandem with the maturation of third party risk management programs, the standards and best practices for secure cloud services are beginning to coalesce. Organizations such as the Cloud Security Alliance are fostering collaboration between the providers and consumers of cloud services, working together to define best practices and guidance for the secure architecture, operation, and use of cloud services. This knowledge sharing is raising the level of awareness among both providers and consumers, leading to more secure cloud service offerings and better educated consumers of cloud services.
In summary, the future for cloud based security services is bright. As organizations adopt more cloud based IT services, cloud based security services will certainly be part of this movement, bringing innovation, flexibility, cost efficiencies and security.
Andrew Wild is the Chief Security Officer for Qualys (https://www.qualys.com). He has more than 20 years of experience leading teams to design, implement and operate secure networks and computer systems. As Qualys’ Chief Security Officer, Andrew oversees the security, risk management and compliance of its enterprise and SaaS environments. Prior to joining Qualys, he managed a team of information security engineers responsible for the design, implementation and operation of security solutions for EMC’s SaaS offerings, with heavy emphasis on cloud and virtualization technologies. Prior to EMC, he was the Chief Security Officer at Transaction Network Services. He has also held a variety of network engineering leadership roles with large network service providers including BT and Sprint. Andrew has a master’s degree in electrical engineering from George Washington University and a bachelor’s degree in electrical engineering from the United States Military Academy. He is a veteran of the United States Army.
January 9, 2014 | Leave a Comment
By Dan Dagnall, Chief Technology Strategist for Fischer International Identity
Federation is definitely a hot topic these days, with NSTIC attempting to create an identity ecosystem, InCommon continuing to build its service-providerfederation, and state-level initiatives gearing up (some are already operational) to provide federated identity services to 4-year schools, community colleges, K-12, and every entity in between. But I’ve found that many institutions and schools are not prepared to commit to the rigorous list of technical requirements to enter into such federations. This is primarily because of a lack of talent, lack of budget, and resource utilization constraints.
Institutions that choose the federated identity path faceother potential roadblocks.The standard model requires a unique Shibboleth installation (which by default,would provide a localized identity provider(IdP) login screen and a custom URL for the login screen)which is simply not appropriate for smaller colleges and universities that can ill afford to hire more technical talent. Localized IdPs are also not feasible for K-12 as they would require technical resources to be located at each school.
A Cloud-based identity provider (cIdP) model is the best option for institutions that don’t currently have any SSO capabilities as it eliminates 90% of the technical federation hurdles. As a result, this model should resonate well with smaller colleges and universities, K-12, and other entities lacking the key components to enter the secure world of federated identity management. The only real difference between a Cloud-based IdP and a localized one is you will typically spend half the money and 90% less time to deploy a Cloud-based IdP than a localized one. And I can find no reason why entities falling behind in the federated world shouldn’t consider deploying a Cloud-based IdP.
The Cloud-based IdP model reduces costs through economies of scale by securely sharing resources among multiple institutions. In contrast tolocal IdPs,which require at least one instance of Shibboleth software to be installed for each institution, each with its own set of metadata to be configured, and each of these with its own maintenance by technical specialists, all of which add to costs, the Cloud-based IdP model is a far simpler approach. EachCloud-based IdP needs only a single installation of the Shibboleth software and a single set of metadata to accommodate multiple institutions, which dramatically reduces the on-going support compared to supportingat leastone IdP per entity. It is also important to note that because the Shibboleth software does not reside on campus, there is no need for each individual campus to have any technical federation knowledge. Therefore, the Cloud-based model unlocks the door to the federated world for institutions that lack talent, time, money or all three. In fact, ifwe judge success by a massive uptake of federation, then using Cloud-based IdPs provides the best chance for success.
However, every new technology has its critics, and Cloud-based federation is no exception:Some people believe that the federation identity provider(IdP) should always be local (i.e., on-campus) and therefore, unable to leverage the Cloud for IdP services. Perhaps this is because some in the industry are not yet comfortable with a Cloud-basedapproach, possibly out of a lack of understanding regarding security and risk for a Cloud-based versus an on-campus IdP.I’ll address their concerns in turn.
Some criticsassert that a cIdP is not secure, but security issues for a Cloud-based IdP are no different than for a localized IdP deployment. In both cases, SAMLis the underlying protocol, with the same security mechanisms in place, the same configuration in place, the same platforms are leveraged, and the same application set is accessible. Also, service providers hosting cIdPs are often more secure and frequently provide higher availability than many institutions can achieve locally.
Some critics argue that a Cloud-based IdP is never feasible because they believe there is a lack of capabilities for institutionalbranding. But, Cloud-based IdPs have the same branding options as local IdPs,and the user experience for the Cloud-based login process is identical toa fully-branded and customized local IdP deployment.
Some federationstry to disallow Cloud-based IdPs into their trust models, presumably because they don’t believe that Cloud-based IdPs are as trustworthy, or possibly the federation managementlacks understanding of the implications that cIdPs have (or don’t have) on their businesstrust models. From a technical perspective,Cloud-based IdPs are often more trustworthythan local IdPs:Typically,the data center is more secure, access to the data is more secure, and so on.From a business perspective, although the technical aspects of a cIdP areoutsourced, the business trust model remains unchanged and between the same parties, as business agreements are not outsourced.
Some critics advocate for localized IdPs while at the same time supporting internal deployments of dirSynch or Google’s synch process to provide Cloud-based email services to their user populations, which, by the way, stores user data in the Cloud. So if the issue is related to where the data is stored, then their logic is flawed as they are advocating both sides of the same coin. It’s like they’re cutting off their noses to spite their faces.Maybe their real issue is with reporting, as reporting actual IdP installations might look better to some people than reporting the same number of institutions on Cloud-based IdPs? Or maybe some people are simply attempting to undermine commercial solutions in attempt to supporttheir own pet open-source initiatives?
All things considered, Cloud-based identity providers scale much better than localized IdP / federated infrastructures. Cloud-based IdPs are just as secure and trustworthy (often more so), and are more cost effective for institutions tasked with federating their users to access service providers. My advice: don’t discount a Cloud-based approach, as aCloud-based IdP can quickly be operational, can be configured easily, and can federate your users in a fraction of the time it takes to deploy your own infrastructure.
December 10, 2013 | Leave a Comment
By Krishna Narayanaswamy, chief scientist at Netskope
As computing shifts to the cloud, so too must the way we enforce policy.
Until recently, enterprise applications were hosted in private data centers under the strict control of centralized IT. Between firewalls and intrusion prevention systems, IT was able to protect the soft inner core of enterprise information from external threats. Ever more sophisticated logging and data leakage prevention solutions supplemented those with a layer of intelligence to help IT identify and prevent not only external but also internal threats that led to costly data breaches. Even remote workers were shoe-horned into this centralized model using VPN technology so they can be subjected to the same security enforcement mechanisms.
The cloud has brought so many benefits, with users of compute services being able to procure the service that best fits their needs, independent of the others, and providers able to focus on what they do well, whether building scalable infrastructure or solving a business problem with a software service. The distributed nature of the cloud also means that users enjoy the availability and performance benefits of multiple redundant data centers. The model also aligns well with the proliferation of smart devices and users’ need to access content anywhere, anytime.
But as computing has moved to the cloud – and we are now at a tipping point with nearly one-third of compute spend reported to be on cloud infrastructure, platform, and software services – legacy security architectures are quickly becoming ineffective.
We need a fresh way to solve the problem. But first a short primer on security policy enforcement:
Security reference architectures consist of two components: the Policy Control Point (PCP) and Policy Enforcement Point (PEP). The PCP is where security policies are defined. In general, there is one or a small number of PCPs in an enterprise. The PEP is where the security policies are enforced. Typically there are many PEPs in an enterprise network, and a group of PEPs may enforce a specific type of policy.
The way it works is the PCP updates the many PEPs with the specific policy rules that pertain to the PEPs’ capabilities. The PEPs, for their part, act in real-time on the policy trigger, such as discovering data passing through a network and enforcing the policy as a pre-defined triggered action happens. PEPs that experience a policy trigger then send policy event logs back to the PCP to convey the attempted policy violation and confirm enforcement for compliance reporting purposes. Event logs provide information from the PEP about how and when the policy was triggered that can be used to create new or tune existing policies.In practice, the PCP and PEPs are usually not a single physical entity but a collection of physical entities that provide the logical functions described above.
What are the key requirements for a cloud security framework?
The fact that enterprises’ applications, platform, and infrastructure servicesare moving to the cloud breaks the notion of a centralized service delivery point.Cloud service providers have optimized their ownsolutions for the specific types of services they’re offering or enabling, e.g., CRM, backup, storage, etc.This means that there are no common security controls across all of the services that enterprises are accessing.
Adding insult to injury, enterprises have another dimension of complexity to deal with: They need to plan for users to get both on-premand off-prem access to enterprise apps, as well as access from corporate-owned and personalsystems and a plethora of mobile devices. And in the face of all of this complexity, of course, the service and the policy enforcement needs to be efficient, as transparent as possible, and “always on.”
A tall order.
What are the ways to ensure this?
One possibility is the status quo: Ensure that all access to cloud services from any device, whether corporate-owned or BYOD are backhauled to the enterprise datacenter where the PEPs are deployed. This approach creates an hour-glassconfiguration where traffic from differentaccess locations is funneled to a choke-point and then fans out to the eventual destination, which is generally all over the Internet. Great for policy enforcement. Not so much for user experience.
Another possibility is to enforce policies at the server end. This is more efficient from a traffic standpoint, but isn’t effective because every cloud serviceprovider has a proprietary policy framework and different levels of policy enforcement capabilities. This means the PCP has to be able to convert the configuredpolicies to the specific construct supported by each service provider.
A third possibility: Distributed cloud enforcement (in case you haven’t guessed it yet, this is the recommended one). This involves distributing PEPs in the cloud so that traffic can be inspected for both analytics and policy triggers, irrespective of where it originates. It also means that PEPs will be deployed close to user locations, allowing for minimal traffic detours enroute to theapplication hosted by the cloud service provider. The distributed PEPs are controlled by a central PCP entity. This all sounds very easy, and of course, the devil is in the details.
In order to do this right, the solution enforcing the policies must employ efficient steering mechanisms in order to get traffic to the PEPs in the cloud. The PEPs must enforce enterprises’ security policies accurately and quickly, and send those policy logs to the PCP in a secure, reliable way each and every time. This reference architecture resembles legacy architecture in terms of the level of control it provides while obviating the need to backhaul traffic back to the enterprise datacenter. The PEP only has to provide the various security functions that were deployed in the datacenter: access control, data loss prevention, anomaly detection, etc.The architecture also provides an option for introducing new services that are relevant to the emerging trends. For example, with corporate data moving to the cloud which is not in the direct control of the enterprise, data protection becomes an important requirement. The cloud resident PEP scan provide encryption functionality to address this requirement, among other non-security capabilities such as performance, SLA, and cost measurements.
It’s clear that emerging trends like cloud and BYOD have obviated existing security architectures.We are not alone in addressing this issue. Organizations such as the Cloud Security Alliance, which recently kicked off its Software Defined Perimeter (SDP) initiative, are looking hard at the best ways to tackle this. I submit that addressing the above trends with a distributed cloud policy enforcement framework meets key requirements and provides a foundation for adding new security (and non-security) services that will become relevant in the near future.
December 9, 2013 | Leave a Comment
CSA members are invited to join the Security-as-a-Service Working Group (SecaaS WG) which aims to promote greater clarity in the Security as a Service model.
Why a Security as a Service Working Group?
Numerous security vendors are now leveraging cloud based models to deliver security solutions. This shift has occurred for a variety of reasons including greater economies of scale and streamlined delivery mechanisms. Regardless of the motivations for offering such services, consumers are now faced with evaluating security solutions which do not run on premises. Consumers need to understand the unique nature of cloud delivered security offerings so that they are in a position to evaluate the offerings and to understand if they will meet their needs.
Research from this working group aims to identify consensus definitions of what Security as a Service means, to categorize the different types of Security as a Service and to provide guidance to organizations on reasonable implementation practices.
As part of its charter, the group expects to publish three key pieces of research related to the Security as a Service model over the course of the following six months
1. A Category Framework Proposal. This will include business and technical elements as well as a survey on this framework proposal and how it applies to existing categories
2. Categories of Service v2.0. This document will include sections based off of the new framework
3. Implementation Documents v2.0,. These implementation documents will include templates based off of the new framework as well business and technical elements as well as a detailed guidance.
To get involved, visit the SecaaS Working Group page.