Earlier this week PC World reported that a security researcher at FireEye took down a major botnet, Mega-D. However, LonerVamp weighed in with a more objective analysis of what FireEye accomplished.
I like the idea of maturity models as they can help an organization improve the state of a process in an organized fashion and enables the organization to compare itself to others. The granddaddy of maturity models is Carnegie Mellon University's software development Capability Maturity Model which was started in 1987. Now comes the Building Security In Maturity Model which is focused on building security into the software development process.
Here is the opening paragraph of their web site:
The Building Security In Maturity Model (BSIMM) described on this website is designed to help you understand
and plan a software security initiative. BSIMM was created through a process of understanding and analyzing
real-world data from nine leading software security initiatives. Though particular methodologies differ (think OWASP
CLASP, Microsoft SDL, or the Cigital Touchpoints), many initiatives share common ground. This common ground
is captured and described in BSIMM. As an organizing feature, we introduce and use a Software Security Framework
(SSF), which provides a conceptual scaffolding for BSIMM. Properly used, BSIMM can help you determine where
your organization stands with respect to real-world software security initiatives and what steps can be taken to make
your approach more effective.
The organizers are Gary McGraw and Sammy Migues of Cigital and Brian Chess of Fortify. Cigital and Fortify are both leading vendors in the software security market. Please do not interpret this as a negative. Putting out valuable information for free and enabling two-way communications with users is about as ethical marketing as there is.
They are promoting the very worthwhile and intuitively obvious notion that your software will be more secure if you build security in during design and development rather than bolt it on afterward.
BTW, Carnegie Mellon's Software Engineering Institute is still very active with respect to maturity models. Check them out here. Wikipedia provides a nice summary here.
In light of TSA's reaction to the near-miss catastrophe on Northwest Flight 253 on Christmas Day, I'm glad to see that CNN republished an article by Bruce Schneier entitled, "Is Aviation security mostly for show?"
Dark Reading's December 21, 2009 article, 4 Factors To Consider Before Firing Up that DLP Solution provides welcome insight into the administration requirements of DLP systems. Too often, the press just hypes the latest security solution types (think NAC in 2006 and 2007; where is Cisco's TrustSec?). While DLP is surely not new, this type of article is still refreshing.
The four factors described are:
- Policy – Initial creation and/or customization, ongoing modification
- Data Discovery – Initial and ongoing configuration of data identification algorithms
- Integration – e.g. ICAP, email, encryption
- Administration – Alert Adjudication
The article says that the amount of administrative work is a function of "the size of your organization and the level of deployment." I would add a third – the product you select.
Actually, all security products require at least Policy Management, Integration, and Alert Adjudication. Therefore when considering adding a new security/compliance solution type, review your overall security/compliance portfolio and consider consolidation opportunities as a way to control administration costs.
While the major security vendors have been acquiring and integrating additional functionality for years, start ups have been coming to market with innovative approaches to unifying functions designed and built from the ground up. Next generation firewalls, as described by Gartner, comes to mind.
Let the payments begin. Heartland Payment Systems settled the lawsuit brought by American Express due to Heartland's 2008 breach of 130 million credit cards (which I wrote about here) for $3.6 million. There are still many more lawsuits outstanding including Visa and MasterCard which no doubt represent the majority of the credit cards stolen.
The article quotes Heartland CEO, Bob Carr, as saying that Heartland "has set aside $12.6 million to charges related to the hack." I find this number to be a gross underestimation considering that TJX believes its breach will cost $250 million as reported here, here, and here.
i just stumbled on a blog post by John Oltsik of ESG entitled Database Security Is In Need of Repair written on August 26th, 2009. John reports on a survey ESG conducted that showed Database Security is surprisingly weak given the fact that 58% of the survey respondents said that databases contain the highest percentage of their organizations' confidential data. File Servers came in a distant second at 15%.
How can this be? John says:
1. No one owns database security, rather it appears to be a collective
effort done by security administrators, IT operations, data center
managers, system administrators, DBAs, etc. With this many people
involved, it is likely that database security is fraught with redundant
processes, numerous "root" access passwords, and human error.
This resonates with my experience. The worlds of DBAs and IT Security professionals rarely meet. They speak different languages. DBAs are all about availability and performance, just as network administrators traditionally were.
There are two types of Database Security solutions – Encryption and Database Activity Monitoring. Encryption solutions are used for compliance purposes, for example to encrypt the Social Security Number column of a database o block unauthorized users who gain access to the database server. However, it does nothing to block authorized users violating access policies.
Database Activity Monitoring, which I wrote about here, comes in three flavors – logging, network, and host based. In some cases, Database Activity Monitoring can provide a layer of policy control to restrict authorized users (insiders) to just the data they need to do their jobs. And even of those solutions there can be limitations.
In summary, 1) the solutions available are improving and 2) it behooves database administrators to expand their vision to include database security.
The Verizon Business security forensics group's recently released 2009 Data Breach Investigations Supplemental Report provides common ground between those in the enterprise who are compliance oriented and those who are security oriented. While in theory, there should be no difference between these groups, in practice there is.
Table 8 on page 28 evaluates the breach data set from the perspective of data types breached. Number one by far is Payment Card Data at 84%. Second is Personal Information at 31%. (Obviously each case in their data set can be categorized in multiple data breach categories.) These are exactly the types of breaches regulatory compliance standards like PCI and breach disclosure laws like Mass 201 CMR 17 are focused on.
Therefore there is high value in using the report's "threat action types" analysis to prioritize risk reduction as well as compliance programs, processes, and technologies.
While the original 2009 DBIR did provide similar information in Figure 29 on page 33, it's the Supplemental report which provides the threat action type analysis that can drive a common set of risk reduction and compliance priorities.
The first adjudicated lawsuit against the executives of Heartland Payment Systems went in favor of the defense.
As I am sure you aware, Heartland Payment Systems is embroiled in countless lawsuits as a result of the disclosure it had to make in January 2009 of a breach of over 130 million credit card numbers. It is considered the largest breach of credit card data in history.
A class action shareholder lawsuit filed against the executives of Heartland was dismissed earlier this month by Judge Anne Thompson of the U.S. District Court of New Jersey on the basis that the executives' claim that they took security seriously was not a lie. Here is the actual opinion.here.
Gene Schultz weighed in with a thoughtful opinion here.
While I am no lawyer, it seems to me that this lawsuit was very narrowly focused and based on my reading of the opinion, it's hard to see how the judge could have found for the plaintiff.
A lawsuit that would bring out the emails and memos associated with a variety of compliance and security decisions made by the Heartland executives would be more interesting.
On November 30, 2009, the US-CERT classified the design of the popular Clientless SSL VPN class of products as a vulnerability – US-CERT Vulnerability Note VU#261869. In other words, the method by which Clientless SSL VPNs work creates a vulnerability for which there is no direct fix. The issue is that Clientless SSL VPNs, by design, subvert the "same origin policy" of web browser programming languages. The policy is described here and here.
This is by no means the first time this vulnerability has been written about – see Michal Zalewski's article of June 6, 2006, which provides a lucid attack example. Cisco acknowledged MZ's references to Cisco's SSL VPN here.
All software products contain security flaws. Most of them are implementation bugs that are more or less straightforwardly fixed in a patch or a new release. Occasionally a vulnerability is the result of a design flaw. However, this is the first time that I am aware of when a security product class is architecturally flawed at it's design level.
