This year, my schedule at the RSA Conference 2012 was much different than previous conferences. As a speaker, I spent quite a bit of time preparing and rehearsing my presentation, as well as talking with other presenters. Of course, audiences get a lot out of the presentations and meeting the presenters afterwards, but it's a step up to be able to meet and talk with presenters informally about the industry, security issues and solutions for customers, and the direction of technologies.
Looking back at the past year and the significant number of huge data loss events, I thought I saw that people were looking to step up their game against breaches. I liked what I heard from industry industry leaders - concepts with the potential to improve data security: 1) better communication and interaction between software development and operations, such as Josh Corman and Gene Kim's Rugged DevOps talk, 2) improving security functionality for cloud - Chris Hoff and Rich Mogul's Grilling Cloudicorns talk, and 3) improving mobile device security.
I'm looking forward to digging into these ideas further in the coming year.
Wednesday, March 14, 2012
Thursday, February 2, 2012
RSA Conference 2012 - Data Breaches and Web Servers: The Giant Sucking Sound
I'm scheduled to present "Data Breaches and Web Servers: The Giant Sucking Sound" at RSA Conference 2012 - session DAS-204 on Wednesday, February 29.
From the abstract:
Hope to meet you at the RSA Conference!
Guy
From the abstract:
An analysis of recent data breach events shows a large number of events occur via web servers. Barracuda, Epsilon, Citigroup, eHarmony, Sony and the State of Texas are just a few of the names in the news as a result of web data exposures. Web servers in the cloud only complicate the situation. This presentation will examine technologies and practices you can apply to help keep your name off this list.Since I submitted the abstract several months ago, there have been several additional major breaches of web servers including Stratfor, Zappos and Care2, so the giant sucking continues.
Hope to meet you at the RSA Conference!
Guy
Tuesday, January 10, 2012
Cloud Security - Hardware Support for Isolation?
Recently, Joanna Rutkowska wrote that IaaS cloud services are insecure without hardware support for separation between tenants, citing Bruce Schneier's recent article on cloud insecurity.
However, successful IaaS cloud services like Amazon Web Services are enabled by commodity hardware (using the Intel x86 instruction set), free operating systems (Linux), and the ubiquitous TCP/IP and SSL protocols. Today's IaaS providers already have massive investments in commodity hardware, and hardware support for tenant isolation would seem to be a ways off, both in hardware development and adoption by providers.
I am more concerned about SaaS services and isolation of clients. How I can be sure my Office365, SalesForce, or other SaaS service can successfully and permanently isolate and protect my company's data? I don't see how hardware support for isolation can be extended into the realm of SaaS services unless it is in terms of per-customer encryption of data.
Your thoughts?
However, successful IaaS cloud services like Amazon Web Services are enabled by commodity hardware (using the Intel x86 instruction set), free operating systems (Linux), and the ubiquitous TCP/IP and SSL protocols. Today's IaaS providers already have massive investments in commodity hardware, and hardware support for tenant isolation would seem to be a ways off, both in hardware development and adoption by providers.
I am more concerned about SaaS services and isolation of clients. How I can be sure my Office365, SalesForce, or other SaaS service can successfully and permanently isolate and protect my company's data? I don't see how hardware support for isolation can be extended into the realm of SaaS services unless it is in terms of per-customer encryption of data.
Your thoughts?
Wednesday, December 21, 2011
Web Server Security Checklist
Here is a quick checklist of items I have found to be important in securing and monitoring the security of outward-facing web servers.
Architecture
Typical components surrounding a web server include an external firewall to protect the web server itself from attacks and an internal firewall to protect the internal corporate systems in case the web server is breached.
Hardening
Operating systems and web server software packages often come with additional components that may not be necessary. Rather than leaving unused but potentially vulnerable software available on a web server, it is wise to disable and/or remove any unused software.
Ensure directories and files have appropriate access permissions - does the web server process really need read access to the entire filesystem?
Remove default system accounts. Ensure accounts with access to the server have appropriate passwords.
If you have a host-based firewall on the web server, limit access to administrative functions (SSH or remote terminal services). Limit outbound network connections from the server to only necessary sites and/or protocols.
Patching & Updating
It is amazing how many web servers I have found that are running operating systems, web server software, or web applications that are long outdated and likely to have substantial vulnerabilities. It's important to stay abreast of known vulnerabilities and vendor patches, and have a working plan to evaluate, apply, and test patches for all the software on the web server as well as the other servers and network devices associated with the web server.
I subscribe to the SANS @Risk Consensus Security Alert mail list to stay informed of vulnerabilities and patches in major operating systems and applications.
Web application firewall
Even the best-run and maintained systems can have latent vulnerabilities hiding in the software and/or configuration. Web application firewalls can help protect against attacks such as SQL injection which are otherwise all too commonly successful.
I have made use of the mod_security Apache plug-in module and rules to protect web servers. Many commercial web application firewall devices are available, and even cloud-based web application firewall services are available.
Penetration testing
It's not a bad idea to have a third-party check your web site using penetration testing techniques to check for potential network, operating system, web server, and web application vulnerabilities and mis-configurations.
I have not used it, but I understand the BackTrack bootable Linux CD provides a nice collection of tools to perform penetration testing. Otherwise, there seems to be quite a few consultants willing to perform penetration testing.
Log monitoring
Of course, a busy web site can generate a large amount of log data every day. Tools like awstats can be useful to build an understanding of typical usage loads, top pages, and user demographics.
I have also found looking at failed requests (4xx responses) to be interesting because one can see what approaches attackers are using against web sites, and can help make sure that defenses are working properly.
Auditing
If a system seems to be running OK, why bother looking for trouble?
- What if you have outdated administrative accounts, some of which probably have poor passwords?
- What if a piece of software was installed at some point that unexpected opened access permissions in the filesystem?
- What if, during a hasty period of diagnosing and resolving a significant issue, permissions were changed in the filesystem or in the web server configuration and never were restored?
- Or, what if an attacker has gained access to the server and is siphoning data into a hidden directory for later download?
Make time to audit your web server regularly and look for unexpected changes in files, permissions, or access, check logs, and verify installed software and patches.
Data loss monitoring and prevention
Data loss monitoring and prevention systems should have a place in high-stakes web services. These systems can monitor the type and quantity of data that is coming out of a web server or the database, and raise alerts or block results that violate rules. These systems can be put in place either in front of the web server or the database server to monitor requests and responses.
Monday, November 14, 2011
Data Loss Prevention: Technology or Strategy?
As often happens in the computer industry, nomenclature is unwieldy and flexible as technologists, sales & marketing, and the rest of the world clash.
My case in point is the phrase "data loss prevention" or DLP. In other articles, I have talked about DLP as a technology -- in that it is used to analyze the content of a document or message, determine whether the content references a concept confidential or protected in nature, and uses rules or reporting to handle the content. As the concept of DLP was developed in the last decade, the industry struggled to find an appropriate phrase that defined it: phrases including content monitoring & filtering, content analysis, deep packet inspection, and others were used, but the industry and analysts settled on data loss prevention.
Many companies are marketing "data loss prevention" in relation to their technologies, but not in the context of analysis of document content. Instead, their approaches include building a wall around all corporate data (such as on a mobile device, or in a cloud-based document-sharing service), or providing some regular expression matching for message content. This is well and good, but I would suggest these technologies fall under the larger strategy of information protection rather than being specifically about "data loss prevention".
This goes to the heart of the matter: when we build true data loss prevention systems, the intent is to protect confidential information rather than just bits and bytes of raw data. Under the fundamentals of information theory, data is just bits and bytes, but information is found where there is entropy, or value, in the data. This is what distinguishes data loss prevention technology from other data protection technologies, and perhaps the better phrase for the technology would be "information loss protection."
Practically, though, we are probably stuck with the labels that have been adopted. So, I suppose we can accept a variety of technologies under the strategy of data loss prevention, including the technology of data loss prevention itself. Unfortunately, this will continue to be confusing to those inside and outside of the industry and troublesome for sales and marketing.
My case in point is the phrase "data loss prevention" or DLP. In other articles, I have talked about DLP as a technology -- in that it is used to analyze the content of a document or message, determine whether the content references a concept confidential or protected in nature, and uses rules or reporting to handle the content. As the concept of DLP was developed in the last decade, the industry struggled to find an appropriate phrase that defined it: phrases including content monitoring & filtering, content analysis, deep packet inspection, and others were used, but the industry and analysts settled on data loss prevention.
Many companies are marketing "data loss prevention" in relation to their technologies, but not in the context of analysis of document content. Instead, their approaches include building a wall around all corporate data (such as on a mobile device, or in a cloud-based document-sharing service), or providing some regular expression matching for message content. This is well and good, but I would suggest these technologies fall under the larger strategy of information protection rather than being specifically about "data loss prevention".
This goes to the heart of the matter: when we build true data loss prevention systems, the intent is to protect confidential information rather than just bits and bytes of raw data. Under the fundamentals of information theory, data is just bits and bytes, but information is found where there is entropy, or value, in the data. This is what distinguishes data loss prevention technology from other data protection technologies, and perhaps the better phrase for the technology would be "information loss protection."
Practically, though, we are probably stuck with the labels that have been adopted. So, I suppose we can accept a variety of technologies under the strategy of data loss prevention, including the technology of data loss prevention itself. Unfortunately, this will continue to be confusing to those inside and outside of the industry and troublesome for sales and marketing.
Friday, August 12, 2011
Five Stages of Cloud Acceptance
Denial: We'll never put anything in the cloud because of security/reliability/performance/etc.
Anger: You already put WHAT in the cloud? How are we going to do backups/switch providers/manage identity/etc.???
Bargaining: OK, we'll move X into the cloud if/when the cloud becomes secure/reliable/etc.
Depression: The CFO/CEO/etc. wants us to start using cloud to save money/reduce costs/expand functionality. We can't use the cloud. What about my job running the data center? What about our bandwidth? What about PCI DSS/HIPAA/GLBA?
Acceptance: It works, I can do more to enable my company's business, and reduce capital expenditures. Let's put everything into the cloud!
Seriously, I have had some of these reactions myself. I hear some of these reactions from people when we talk about using cloud services and realize there truly is a road to acceptance for many people.
Anger: You already put WHAT in the cloud? How are we going to do backups/switch providers/manage identity/etc.???
Bargaining: OK, we'll move X into the cloud if/when the cloud becomes secure/reliable/etc.
Depression: The CFO/CEO/etc. wants us to start using cloud to save money/reduce costs/expand functionality. We can't use the cloud. What about my job running the data center? What about our bandwidth? What about PCI DSS/HIPAA/GLBA?
Acceptance: It works, I can do more to enable my company's business, and reduce capital expenditures. Let's put everything into the cloud!
Seriously, I have had some of these reactions myself. I hear some of these reactions from people when we talk about using cloud services and realize there truly is a road to acceptance for many people.
Changing Face of "Spam" Email
As a network engineer involved in bringing up some of the first Internet connections in the upper midwest in the late 1980s and early 1990s, I also managed email systems in the 1990s as spam email started becoming a nuisance. In the past decade, spam has been more than a nuisance - email systems must have effective spam filters to keep email usable for end users.
There is an interesting trend I see now - I am getting a fair bit of relevant business-related marketing email in my inbox. The amount of "online pharmacy" spam is way down, but I still get a fair amount of complete junk, including a lot of Cyrillic and Mandarin spam that is completely unintelligible to me. Fortunately, my company's spam filter, including up-to-date SpamAssassin rule lists and a good blacklist, are doing a good job discarding and classifying the useless spam, while allowing through the reasonable marketing queries (I think).
A few years back, the sales team at my employer emailed potential customers asking if they could setup meetings to introduce the company's software - not an unusual email message, especially nowadays. One particular recipient hit the roof and replied with a rant worthy of a response to the first massive Usenet spam from the green card lawyers back in the day.
Are people's attitudes changing about spam? Is there an increasing acceptance of reasonable marketing-type contact via email?
There is an interesting trend I see now - I am getting a fair bit of relevant business-related marketing email in my inbox. The amount of "online pharmacy" spam is way down, but I still get a fair amount of complete junk, including a lot of Cyrillic and Mandarin spam that is completely unintelligible to me. Fortunately, my company's spam filter, including up-to-date SpamAssassin rule lists and a good blacklist, are doing a good job discarding and classifying the useless spam, while allowing through the reasonable marketing queries (I think).
A few years back, the sales team at my employer emailed potential customers asking if they could setup meetings to introduce the company's software - not an unusual email message, especially nowadays. One particular recipient hit the roof and replied with a rant worthy of a response to the first massive Usenet spam from the green card lawyers back in the day.
Are people's attitudes changing about spam? Is there an increasing acceptance of reasonable marketing-type contact via email?
Subscribe to:
Posts (Atom)