Posts Tagged ‘Cloud’
Posted by Heather Howland in Cloud Security, Security Intelligence
While I only have one first cousin, we have bizarre similarities and notable differences. First off, she’s 12 and about ten times smarter than I am (yes, I set myself up with that one). We share some slightly similar facial features, personality traits, and food tastes that favor northern Italian cuisine. She is an accomplished violinist already. I hack at my guitar every once in a blue moon. Anyway… enough kicking myself in the teeth.
What does this have to do with SIEM and cloud computing? Similar to my previous “cloud security” themed post, I will again reference the best practices paper by Q1 Labs’ CSO Chris Poulin. In this, he suggests that SIEM itself provides a cloud-type capability and is structurally similar. I find this a very interesting correlation and pretty darn accurate in many ways. Lets get into it.
A classic SIEM is fed data from all around an organization via different groups with varying requirements and responsibilities. These groups cross organizational divides and often have very different interests, data types, and use cases. SIEM has definitive customers and providers, as do cloud providers. For example, the systems management group may feed Microsoft Windows Active Directory events into the SIEM to be alerted on user login failures, signaling a brute-force password attack or escalation of privileges attempt.
Cloud providers are fed data from different customers, expecting their data to be protected, segmented from other customers, controlled, secured, and monitored. A cloud provider is also expected to not access customer data for their use or benefit unless allowed by the customer. While this may not 100% correlate to a SIEM environment, there are contractual obligations between the operational management function and SIEM consumers to ensure processes are in place to handle potential incidents, empowering the data owners and developing a clear escalation process.
Related: What’s in a cloud security plan?
This points out one of the differences between cloud and SIEM, and why they might be cousins, yet only distant cousins. The SIEM provider generally has total context and an overarching security responsibility, otherwise known as security intelligence, that spans across data from all groups. For example, correlating vulnerability scanner results with firewall logs and network activity to detect an active threat. In the case of cloud services, there is a clear dividing line between roles and responsibilities; especially involving customer data. The data belongs to the customer and has to be treated differently. An example is GMail. Most likely, it wouldn’t be accepted if Google started reading our email or forwarding it to other GMail users. Okay, they are reading it, but hopefully not forwarding.
What do you think, are there other similarities between cloud and SIEM? Besides SIEM being a lot smarter than cloud, that is.
Learn more about IT Security best practices in cloud environments.
Posted by Heather Howland in Cloud Security, Security Intelligence
Q1 Labs’ CSO, Chris Poulin, recently authored a paper defining best practices for IT Security in a cloud environment. In this, he covers some interesting viewpoints on various hurdles expected when organizations secure their public or private cloud environments, as well as the steps necessary to create an effective security policy, and the similarities between SIEM and cloud environments.
Since this is a week of two major cloud related conferences - VMworld and Dreamforce – let’s talk cloud security!
What are a few of the steps cloud providers and customers can take when building out their own cloud security plan? One major chunk of the process is to start with an assessment of risk. That is, understand your current data types, locations, business processes, and information flow. Understand where the critically sensitive data is. Just like any other enterprise, cloud computing requires customers and cloud providers to define their own information topology before any reasonable security policy can be defined and implemented.
Step 1: Discovery
Know where all of your data is, no matter how you classify it. The key is uncovering the difference between the data that can and cannot be housed in the cloud. An eDiscovery process is recommended to locate buried and even misplaced data. Too often organizations find that Personally Identifiable Information (PII) is mixed with less critical data and matched with the wrong security protocols.
Step 2: Classification
After understanding where your data is, it needs to be classified appropriately and distributed to systems with security controls to match the data sensitivity. This step alone can help you make progress meeting various compliance regulations.
Step 3: Data transit
SIEM can help define your data transit policy by monitoring endpoints, firewalls, and network activity to govern if the data should be allowed to proceed to the cloud or not. Content-aware network profiling from Data Loss Prevention (DLP) solutions can fed to the SIEM to perform more complex correlations with other data feeds. For example, watch for PII such as a social security number in a patient healthcare record and combine that with the firewall logs and network activity found within a SIEM to gain a bigger picture of malicious activity.
As Chris Poulin has blogged, there is no question that more modern SIEM (a.k.a. Security Intelligence) solutions have their place in the cloud. It’s not a matter of if SIEM is ready for the cloud, but if the cloud is ready for SIEM. For more on IT Security best practices in cloud environments, take a spin through Chris’ complete writeup.
Related: SIEM and Cloud might be cousins
Posted by John Burnham in Cloud Security, Compliance, Cybersecurity, In the Industry
Day 1: we participated in a panel at the William Blair Technology Symposium, “The Future of Cloud Computing.” The panel was entitled, “How the Cloud Changes Security”. Great topic, great panel, staffed by security solutions suppliers. Major takeaway based on the questions asked of the panel, by the investment community, not end-users: confusion reigns supreme, and most likely due to the outrageous amount of hype surrounding “cloud”. Usually the questions were about virtualization, but using cloudy(ed?) language.
Day 2: Q1 Labs Customer Council. The topic of Cloud came up twice: once in the form a customer’s presentation of one of his major use cases: SIEM as the security intelligence platform for his companies cloud-based services offerings. He relies on QRadar for visibility/compliance and intelligence/threat management to both ensure the integrity of his brand and to provide proactive threat management. And once from another customer in the form of a question, essentially: “What is the role of SIEM in the Cloud, in your opinion?” This generated a very grounded discussion of the various cloud types (private, public, hybrid, multitenant) and how SIEM, Log Management, Vulnerability Management play a role. Clarity prevailed: one size does not fit all use cases.
Prosodie (France) another customer, recently announced their adoption of our QRadar Security Intelligence Platform for both visibility/compliance for their cloud-based services and in addition uses QRadar SIEM from Q1 Labs for intelligence/threat management of their internal network, similar to the customer referenced above.
So, customers view cloud clearly (like how I did that?) as a potentially viable business proposition worthy of examination, versus a cool technology shift: if cloud adoption enables them to do their jobs better and grow their businesses, great. If not, it drops off the list of priorities.
And it would appear that while the market observers might be a bit confused about the exact utility and deployment model of the cloud, customers are not, and seem to have a pretty clear vision for SIEM’s role in securing it.
Posted by Chris Poulin in Cloud Security, In the Industry, SIEM
It may not be a popular message in our industry, but I contend that the cloud is not SIEM-ready. Like nuclear power, the cloud is hot (pun intended) and is being rolled out without a fully fleshed-out maturity model. Public cloud providers are looking at it from a traditional defense-in-depth, perimeter security framework: provide protection around the cloud with firewalls, IDS/IPS, host-hardening, etc. The problem is that security needs to encapsulate the data as well as the infrastructure. Cloud 1.0 isn’t taking that into account: market forces are driving rapid build-out and early adoption. We still lack a full understanding of cloud security needs, and a mature public cloud security model will have to wait until Cloud 2.0
The central issue is the blending of customer data, of which much has already been written: how do cloud providers contend with one bad seed that attracts a criminal investigation? Your data will invariably get mixed in with the malefactor’s and subjected to FBI review. How do cloud providers understand context around customer data and provide targeted mitigating controls?
But it occurs to me that the question today isn’t how we deal with SIEM in the cloud, but rather how does SIEM provide cloud capability? I submit that in medium to large enterprises, SIEM should be managed as an internal security intelligence cloud. SIEMs take in vast amounts of data from many internal groups, and even organizational divides, with different interests:
- The firewall management group may feed logs into the SIEM to be alerted on security events such as port scanning across multiple firewalls which may indicate a low-and-slow (buzzword check: AdvancedPersistent Threat) attempt to breach the perimeter
- The systems management group may feed Microsoft Windows Active Directory events into the SIEM to be alerted on user login failures signaling a brute-force password attack or escalation of privileges attempt
- The network management group may feed flow data into the SIEM to detect denial-of-service attacks or troubleshoot asymmetric routing problems
While many groups feed data into the SIEM, there is one function, usually the security or risk management group, that manages it. This is analogous to cloud services, which have consumers and a provider. When the two are in separate organizations, there’s a clear dividing line between roles and responsibilities. Providers understand that the data belongs to the consumer, its customers, and providers have an obligation to:
- Protect the data under their care, employing the widely adopted Confidentiality, Integrity, and Availability model
- Segment data between customers
- Provide appropriate controls to protect unauthorized access to customer data from external entities and between customers sharing the same cloud
- Avoid accessing customer data for the provider’s use or benefit unless specifically allowed by the customer
- Respond to need of their customers, such as creating reports or adding new users
Think of SalesForce.com or Google Mail: they provide the cloud service and have many customers. They must adhere, contractually, to the tenets above.
Where this model differs between traditional public cloud services and an internal SIEM cloud, is that the SIEM provider generally has an overarching security responsibility that spans the data from all groups. For example, security and risk management need to correlate firewall logs with IPS alerts and network activity to detect threats. The difference is only slight, though, because while Google would not read customer emails, they do provide anti-spam filtering, track usage statistics, and look for intrusion attempts. While privacy advocates may see this as a violation, most consumers are fine with this level of access.
What consumers would not tolerate, however, is if Google decided to start forwarding customer emails to other customers out of their cloud. With a SIEM providing total context, or Security Intelligence as we call it at Q1 Labs, the security and risk management group may detect security threats, policy violations, or other actionable incidents that need to be escalated. This position has to be treated with a level of diplomacy and maturity. You can’t have organizations who manage and consume data from different departments use the data to indict its owners to management: “Our firewalls leave us exposed to XYZ vulnerability.” Just like a public cloud provider, the escalation process needs to be clearly defined and the procedure must include involving the data owners. This ensures that a chain of responsibility is followed and allows the issue to be resolved closest to the group responsible for managing the incident.
The point is, SIEM can bridge the gap between security silos in an organization. There has to be a clear contract between the operational management function and the SIEM consumers. The contract has to separate the duties of the managing entity and prescribe a process for handling incidents and policy violations that empowers the data owners, just like a cloud provider would be obligated to do. When managed properly, SIEM as a cloud engenders trust and cooperation, and ultimately yields a benefit to the SIEM consumers and the business at large.
Posted by Iven Connary in Cybersecurity
So I recently traded my Blackberry for a slick new Droid based smart phone. All in all I must say I’m pretty pleased. What I really love about my phone is my Slingplayer app – providing full cable TV right to my phone… very cool! My random security thought of the day – could the Slingbox architecture become a model for better securing data on a Smartphone?
As the saying goes – “everything old is new again”. There is no doubt in my mind, with the continued adoption of virtual technology, that corporations around the world will again turn to a centralized model of control, but perhaps this time with a new twist – virtualized desktops (AKA a private cloud). I’m actually looking forward to the day when I have an uber-powerful virtual PC within my companies “cloud” that hosts all my applications. A virtual PC that I can access no matter where I am and no matter what device I’m on, including my latest smartphone. Interestingly enough – that seems to be what I can do now with my Slingbox and Slingviewer. While I’m not saying my Slingbox is a 100% secure application, it does seem like it could become secure quite easily. How easily? Well, if the connection between my phone and that magic little Slingbox, sitting next to my cable box, was fully encrypted point-to-point..it would be a pretty secure application. This architecture feels eerily similar to having a centralized virtual PC with a fully encrypted point-to-point channel. I can see the network and security teams salivating over this one for many reasons, the most compelling of which is a regained level of control over the security of enterprise data.
There’s a whole lot to like about this centralized client “cloud” architecture. First, it will greatly minimize the sprawl of confidential data, thereby reducing the risk of breach. Second, it will dramatically improve the ability to securely store, backup and restore data. And finally, it will provide organizations the ability to better monitor access to enterprise systems and data. For more information on this last benefit – see my previous blog post that talks about tricks and tools for better securing a virtual infrastructure.
It’s a reality that smart phones and other mobile internet gadgetry are here to stay. Organizations need to be quick to adapt to the mobile world, and there’s little doubt in my mind that a centralized client side “cloud” is one technology that will become widely adopted. The security benefits are too big to ignore. Perhaps it’s a big leap to think the architecture of my beloved Slingbox will solve all the corporate information security woes, but it feels like its heading in the right direction.
The latest on Cyber Security