Security or compliance?


Mid-size organizations continue to be tossed on the horns of the Security/Compliance dilemma. Is it reasonable to consider regulatory compliance a natural benefit of a security focused approach?

Consider why regulatory standards came into being in the first place. Some like PCI-DSS, FISMA and DCID/6 are largely driven by security concerns and the potential for loss of high value data. Others like Sarbanes-Oxley seek to establish responsibility for changes and are an incentive to blunt the insider threat. Vendor provided Best Practices have come about because of concerns about “attack surface” and “vulnerability”. Clearly security issues.

While large organizations can establish dedicated “compliance teams”, the high cost of such an approach precludes it as an option for mid tier organizations. If you could only have one team and effort and had to choose, its a no-brainer. Security wins. Accordingly, such organizations naturally consider that compliance efforts are folded into the security teams and budgets.

While this is a reasonable approach, recognize that some compliance regulations are more auditor and governance related and a strict security view is a misfit. An adaptation, is to transition the ownership of tools and their use from the security to the operational team.

The classic approach for mid-size organizations to the dilemma — start as a security focused initiative, transition to the operations team.

– Ananth 

Did you know? PCI-DSS forbids storage of CVV


Did you know? PCI-DSS forbids storage of CVV

A recent Ecommerce Checkout Report stated that “55% of the Top 100 retailers require shoppers to give a CVV2, CID, or CVC number during the checkout process.” That’s great for anti-fraud and customer verification purposes, but it also creates a high level of risk around inappropriate information storage.

To clarify, the CVV (Card Verification Value) is actually a part of the of the magnetic track data in the card itself. CVV2/CVC2/CID information is the 3 or 4 digit code on the back of the signature strip of a credit or debit card (or on the front of American Express cards).

The Payment Card Industry Data Security Standard (PCI DSS) clearly states* that there are three pieces of data that may not be stored after authorization is complete (regardless of whether you are handling card-present or card-not-present transactions):

  1. Magnetic stripe data (Track 1 or 2)
  2. PIN block data (and, yes, this means ‘encrypted PIN block’ too)
  3. CVV2/CVC2/CID

– Ananth

Difference between IT search and Log Management


Came across an interesting blog entry  by Raffy at Splunk. As a marketing guy I am jealous as they are generating a lot of buzz about “IT Search”. Splunk has led a lot of people that are knowledgeable to wonder how this is something different than what all the log management vendors have been providing.

Still, while Raffy touched on what is one of the real differences between IT Search and Log Management, he left a few of the salient points out in the discussion of a “connector” and how a connector puts you at the mercy of the vendor to produce the connector, and what happens when the log data format changes?

Let’s step back — at the most basic level in log management (or IT Search for that matter) you have to do 2 fundamental things, you have to help people  1) collect logs from a mess of different sources, and 2) help them do interesting things with them. The “do interesting things” includes the usual stuff like correlation, reporting, analytics, secure storage etc.

You can debate fiercely the relative robustness of collection architectures – and there are a number of differences if you are evaluating vendors you should look at. For the sake of this discussion however most any log management system worthy of its salt will have a collection mechanism for all the basic methods – if you handle (in no particular order) ODBC, Syslog, read the Windows event format, maybe SNMP, throw in a file reader for custom applications, well you have the collection pretty much covered..

The reality is, as Raffy points out, there are a few totally proprietary access methods to get logs like Checkpoint. It is far easier for a system or application vendor to write one of the standard methods. So getting access to the raw logs in some way, shape or form is straightforward.

So here is where the real difference between IT search and Log Management begins.

Raffy mentions a small change in the syslog format causing the connector to break. Well syslog is a standard so if it would not break any standard syslog receiver, what it actually meant is that the syslog message has not changed but the content had.

Log Management vendors provide “knowledge” about the logs beyond simple collection.

Let’s make an analogy – IT Search is like the NSA collecting all of the radio transmissions in all of the languages in the entire world. Pretty useful. However, if you want to make sense of the Russian ones you hire your Russian expert, Swahili, your Swahili expert and so on. You get the picture.

Logs are like languages — the fact of the matter is the only thing that is the same about logs is that the content is all different. If you happen to be an uber-log weenie and you understand the format of  20 different logs, simple IT Search is really powerful. If you are only concerned about a single log format like Windows (although Windows by itself is pretty darn arcane), IT Search can be a powerful tool.  If you are like the rest of us whose entire lives are not spent understanding multiple log formats, or get really rusty because many of us often don’t get exposed to certain formats all the time, well, it gets a little harder. What Log Management vendors do is to help you ( as the user) out with the knowledge – rules that categorize important event logs from unimportant ones, alerts, reports that are configured to look for key words in the different log streams. How this is done is different from vendor to vendor – some normalize, i.e. translate logs into a standard canonical format, others don’t. And this knowledge is what can conceivably get out of date.

In IT Search, there is no possibility for anything to get out of date mainly because there is no knowledge, only the ability to search the log in its native format. Finally, if a Log Management vendor is storing the original log and you can search on it, your Log Management application gives you all the capability of IT Search.

Seems to me IT Search is much ado about nothing…

– Steve Lafferty

Defining SIM/SEM Requirements


The rational approach to pretty much any IT project is the same…define the requirements, solutions, do a pilot project, implement/refine and operationalize.

Often you win or lose early at requirements gathering time.

So what should you keep in mind while defining requirements for a Security Information and Event Management (SIEM) project?

Look at it in two ways:

  1. What are the trends that you (and your peers) have seen and experienced?
  2. What are the experts saying?

Well, for ourselves, we see a clear increase in attacks from the outside.  These are increasingly sophisticated (which is expected I guess since it’s an arms race) and disturbingly indiscriminate. Attacks seem to be launched merely because we exist on the Internet and have connectivity and disconnecting from the Internet is not an option.

We see attacks that we recognize immediately (100 login failures between 2-3 AM). We see attacks that are not so obvious (http traffic from a server that should not have any). And we see the almost unrecognizable zero-day attacks. These appear to work their way through our defenses and manifest as subtle configuration changes.

Of the expert prognosticators, we (like many others) find that the PCI-DSS standard is a good middle ground between loosely defined guidelines (HIPAA anyone?) and vendor “Best Practices”.

The interesting thing is that PCI-DSS requirements seem to match what we see. Section 10 speaks to weaponry that can detect (and ideally remediate) the attacks and Section 11.5 speaks to the ability to detect configuration changes.

Its all SIEM, in the end.

So what are the requirements for SIEM?

  1. Gather logs from a variety of sources in real-time
  2. The ability to detect (and ideally remediate) well recognized attacks in real-time
  3. The ability (and more importantly habit) to extract value from raw logs for the non-obvious attacks
  4. The ability to detect configuration changes to the file and registry level for those zero-day attacks

As the saying goes — well begun is half done. Get your requirements correct and improve your odds of success.

Ananth 

Failed your security audit? Recover with a 5 step checklist


Buying a Pragmatic Log Management Solution Over the past 4 months, we’ve discussed many of the reasons that log management is critical. To quickly review, log management can help you react faster from an operational aspect – so you can pinpoint an incident and remediate any issues well ahead of a significant loss. Secondly, log management helps in the event of an incident in terms of having rock-solid evidence to investigate a breach and hopefully bring the perpetrator to justice.

Welcome to Log Talk


Welcome to Log Talk, the Prism Microsystems blog that provides active commentary and insight on all things related to Log Management and Analysis. Postings on this blog are intended to provide a mix of actionable tips and knowledge to help you leverage your log data as well as provide advice on compliance and security implementations.

Compliance audit got you nervous? It doesn’t have to be that way


Log Management and Compliance In past articles, I’ve covered how log management helps with operations and incident response, all in a distinctly “Pragmatic” way. This month we are going to address what I consider to be the 3rd leg of the stool – compliance. Security professionals have a love/hate relationship with compliance.

How to Disagree with Auditors New EventTracker 6.0 and more


Log Management and Incident Response I’m going to let you in on a little secret. It’s a tough message to get, but part of being Pragmatic is not deluding yourself about what you can and can’t do. The cold harsh reality of today’s information security environment is that you will be compromised. I don’t know whether it will be tomorrow, next Tuesday, or some other time in the future -but it will happen. There are just too many legitimate attack vectors, too many restrictions on what we can and can’t do, and too many limitations on budget and resources to ever be “truly secure.”

Optimize IT operations pinpoint vulnerabilities


Log Management and Pragmatic Operations Last month, I introduced the concept of the Pragmatic CSO methodology, a 12-step program to help security professionals overcome their addiction to throwing new products at every new attack vector and security problem. Additionally, the process helps security professionals build a value proposition, interface with senior management more effectively, and run their security operation as a business. As a high level construct, the 12 steps are helpful, but ultimately security professionals need to do something, and that’s what we are going to discuss this month.

Leveraging Log Data for Better Security


Looking at Log Management Pragmatically As the first article in a 6-part series on the specifics of log management, I want to introduce the concept of the Pragmatic CSO methodology and go into how/why the idea of log management is important to achieving the goals of the Chief Security Officer. This piece will lay the foundation for the journey we will take together over the next 6 months.

Top Security Issues Facing the Enterprise


Collect Vista Events Microsoft has made some considerable changes to event management in Windows Vista. One major change is the way you can now centrally collect events from a variety of systems. This article is the fifth in a series that demystifies the Vista Event Log. Windows Vista includes an updated implementation of Microsoft’s remote management infrastructure: Windows Remote Management (WinRM). The Vista Event Log uses WinRM along with the Windows Event Collector service as the engines for collecting events from remote machines and sending them to a central event collector system.

The New Face of Security Attacks The Danger Within


Automate Vista Events Microsoft has made some considerable changes to event management in Windows Vista. One major change is the way you can link events to automated tasks. This article is the fourth in a series that demystifies the Vista Event Log. When you manage events, you often wish you could generate automatic actions when specific events occur. For example, it would be nice if you could automatically delete temporary files and send a notification to desktop technicians when PC disk drives get too full. In another scenario, it would be nice if you could receive automatic

Data Security and Compliance Regulations


Explore the Vista Task Scheduler Microsoft has made some considerable changes to event management in Windows Vista. One related change is the way the Vista Task Scheduler has been enhanced. These enhancements allow you to link events to automated tasks. This article is the third in a series that demystifies the Vista Event Log.

Explore Vista Event Log; Top Tips on Compliance, Security and Data Privacy


Explore the Vista Event Log Microsoft has made some considerable changes in the Windows Vista Event Log. It sports a new interface and a significant number of new event categories making much more useful than ever before. This article is the second in a series that demystifies the Vista Event Log

OMB Security Mandate and Network Security Best Practices


Industry News Logging data extracts puts some agencies in a bind SPECIAL REPORT: Case study no. 3 – Mandate forces changes in who accesses information OMB gives agencies 45 days to begin logging all computer-readable data extracts, and after 90 days, verify if the data has been erased or still is needed. Very few agencies—if any—have met this most challenging mandate of the four, industry and federal experts said.

New EventTracker 5.6 and Managing Change in Vista


Manage Change in Windows Vista Microsoft has made some considerable changes in the Windows Vista Event Log. How do those changes affect system auditing and how will they change the way you monitor systems? This article is the first in a series that demystifies the Vista Event Log.