The "RISKY BUSINESS" Blog

Having cut my teeth on SIEM in early 2001 (when it was still called SEM) the latest incarnation of Novell's Sentinel product looks as different from those products as the iPhone 3G looks from the Motorola Startac that I thought was so nifty. 

The acquisition of promising SIEM technologies by vendors like Novell with the development and support resources to turn them into enterprise solutions has been great for the industry as a whole and for Sentinel in particular.

Highlights for Novell Sentinel 6.1 include:

• A new single server version optimized for Rapid Deployment to reduce the time and cost to get up and operational.
• An option to run on a full open source stack to reduce costs, improve reliability, and increase resource availability.  The new version leverages Linux/Apache/Jasper/Postgres/ AJAX.  Custom collectors are also now in JavaScript.
• A new stand-alone log collector with very high EPS rates and compressed storage for simpler implementations where full SIEM capabilities are not required. 

I was also lucky enough to get a look at Novell's product roadmap.  It looks like Novell has a few more rabbits up their sleeve that are just around the corner. 

Gartner predicted "healthy revenue growth" for SIEM in the next year -- I guess they had a sneak peek at the Sentinel roadmap.

Don’t miss our white paper – available for download – to optimize SIEM deployment.

On first blush providing credentials to a tiger team conducting penetration tests sounds like giving the fox a key to the chicken coop.  However, there are many cases where it can provide significant value.  For example; you want to assess whether an authenticated user (network or application) can escalate privilege.  Another great place to use credentials is during the Vulnerability Assessment phase of a network Penetration Test.

A network vulnerability scan is essentially a "best effort".  The three predominant challenges to Vulnerability Assessments are;

• The scanner assumes that the host it is interrogating is "trustworthy" (the level of trust is usually adjustable) and bases its assumptions as to the services, versions, and vulnerabilities on the answers it receives. The false positives we are all familiar with are assumptions gone awry.
• The scanner cannot directly assess many important system settings, for example the password policies' complexity setting or the system audit policies event logging settings.
• Packet filtering "devices" in the network path between the scanner and the device (e.g., firewalls, load balancers, routers, network IPs, Host-based IPs) may respond on behalf of the device, providing incorrect data and a false sense of security.

The key benefit to running the vulnerability scan with administrative level credentials is that it allows the scanner to directly assess the system's configuration rather than guess it based on the answers it received.  This not only provides a greater quantity of, and more accurate, information, but it opens up the possibility of using the vulnerability assessment as a compliance check against relevant standards (e.g., PCI, Center for Internet Security, or organization specific).  The last benefit is that a vulnerability  scan with credentials avoids most of the problems encountered with packet filtering devices in the path as the scan is essentially local and authorized.

In a future blog we will look at one of the other unique benefits of running a credentialed scan - running a content scan on the hosts at the same time to determine whether sensitive data (e.g., credit card, medical, identity theft, intellectual property) exists on the systems in violation of policy.

---

Don’t miss our video, from the Master Assurance Series on Network Vulnerability Assessment: Key Decision Points, to help guide you through this valuable tool in the information security arsenal! Find it and more on our Penetration Testing resource page.

Two studies released today from EMC's RSA security division discuss the increased risks posed by cloud-based services and social networking. The 2009 IDG Research Services survey, commissioned by RSA, surveyed 100 security executives at companies with revenues of $1 billion or more. It found that nearly half of those surveyed either have enterprise applications or business processes running in the cloud or are beginning migration in the next 12 months. Yet, two-thirds do not have a security strategy in place for cloud computing.

Of particular interest to me was a quote by Dave Cullinane eBay's CISO "We need to develop an intelligence capability so we know what's coming and we can prevent things from happening in the first place, It means moving to a more preventative security model and being able to share information with each other."

Effective information sharing requires trust. So rather than ask the question "Is the cloud vendor/system/ application secure?" ask the better question "Is the cloud vendor/system/application trustworthy?" 

On first blush, the distinction looks rather minor, as many of the "technical" mechanisms that we choose to assess "trustworthy" are in large part the same that we would use to assess "secure" (e.g., vulnerability assessments, penetration tests, audits, third party attestation, etc.).  However, the value of including trust in the assurance process is that it provides an additional set of measures that we can use to enhance the value and accuracy of the more technical mechanisms. That is, by considering the trustworthiness of the individuals, organizations, and systems, the level of assurance (either positive or negative) provided by the provider/assessor is infinitely increased.

 

 

While we can all agree on the importance of protecting information and information systems, it's much harder to agree on how we define the state of being secure.  Is it the state where all information security risks are completely eliminated (not possible)?  Is it the state where all security risks are mitigated to an acceptable level (which risks and whose definition of acceptable)?  Even if we reach consensus and achieve the agreed upon state - we all understand that it is fleeting and will only last until a change (often outside of our control) denigrates it.

It is because the assurance we receive is often only valid at an "instant in time" (e.g., a penetration test) that trust is so important.  If we don't trust that the person/team/organization responsible to ensure critical information is handled in the manner we aspire to moving forward, then we really have little or no assurance. 

We were recently engaged by a pharmaceutical firm to assess whether a third party developed and hosted implementation of a multi-million dollar clinical trials solution achieved the security objectives defined in the contract. The report would also form the basis of a new contract intended to "remedy" the existing challenges. 

The meeting took a very interesting turn when I asked "Should we really be discussing a new contract when it is obvious that the service provider has proven they are not trustworthy?" (the impact of the vendor failing to achieve critical security objectives could cost the pharmaceutical tens of millions)

For my money, no contract, no matter how carefully worded, will make a company trustworthy.  And without trust we have no confidence/assurance that critical information will remain secure. 

Technorati Profile