Posts tagged: 'compliance'
The following posts are associated with the tag you have selected. You may subscribe to the RSS feed for this tag to receive future updates relevant to the topic(s) of your interest.
http://blog.logrhythm.com/tags/compliance/feedNIST Addressing PII Protection
The National Institute of Standards and Technology (NIST) has drafted a document that specifically addresses Personally identifiable information (PII). The document will become Appendix J of SP 800-53. This means FISMA is likely to change to include these new privacy controls.
What does this mean to you? In the short term, nothing. The standard will be in a public comment period until September 2, 2011, and is not scheduled to be included in SP 800-53 until December 2011 when Revision 4 gets released. After that, it still needs to be updated in FISMA and other regulations derived from SP 800-53.
However, the controls outlined in the draft are significant, and will eventually add extra layers of complexity to an organization’s plan to become compliant. I’m still fully digesting the draft, but something that initially stands out is that NIST is treating PII data similar to how PCI-DSS treats card-holder data, and to how NERC-CIP treats Critical Cyber Assets. For example, control SE-1 in the NIST draft states:
The organization:
a. Establishes, maintains, and regularly updates a PII inventory that contains a listing of all programs and information systems identified as collecting, using, maintaining, or sharing PII;
and
b. Provides each update of the PII inventory to the CIO or other information security officials to support the establishment of appropriate information security requirements for all new or modified information systems containing PII.
This sounds very similar to the approaches in PCI-DSS for defining and securing the Cardholder Data Environment (CDE), or the NERC-CIP Critical Cyber Asset identification.
The draft also adds on all the standard process and procedure requirements, auditing requirements, monitoring, roles and responsibilities, etc, that are seen across the board in other compliance regulations.
While there will still be quite some time before organizations are mandated to adhere to this draft standard, getting a head-start now will save headaches in the future, and protecting PII is simply the right thing to do, regardless of whether it’s mandated by compliance.
Tags: compliance, enterprise security, information security, network security, pci dss
Collect the log data you need without the fire-hose
With all the regulatory and compliance requirements surrounding log and security event management, a typical scenario is to “log everything” – even though the regulation or compliance control objective typically articulates a requirement “…to collect and archive audit trail data”. Audit trails or “interesting” log messages generated by operating systems, applications, or network devices are really a subset of all the logs that are being generated.
This is where a review of logging configurations and what to log is necessary. Every environment and its logging requirements will vary. Some may only need the logs to be collected and archived, others may require the logs to be collected to provide active alerting on configuration changes, and still others may need detailed logging to capture all administrative activities..
In a perfect world, this effort is initiated and supported by management, involving input from a variety of knowledgeable people throughout the organization (e.g. application developers, system administrators, DBAs, auditors, security administrators, etc.). Each system/application/device’s logging capabilities and configurations would be properly to ensure that all desired actions are logged. This allows each group to properly configure logging levels, ensuring that all logs required for security and/or compliance are being retained and made available for analysis.
Whether or not this “perfect world” scenario is feasible, administrators can still follow best practices by configuring and tuning their logging configurations to focus on logs that are pertinent to their requirements.
Given their widespread enterprise footprint, I’ll use Cisco devices as an example of how this can work. Let’s assume you’re required to log and capture only successful logins and configuration changes as well as any operational related errors. Let’s also assume the following:
- Successful Logins = severity level of 6 (Informational)
- Configuration Changes = severity level of 5 (Notifications)
- Error conditions = severity level of 3 (Errors)
It’s common to see logging for Cisco devices to be set with a default configuration logging at severity level 6. This means all logs with severity 6 and higher will be retained generating far more logs than are usually required. But these devices can be easily configured to log to syslog only what is required. With some simple tuning an administrator can stop logging messages showing severity level 6 and 5 while capturing all required log data.
Rather than execute a command to stop logging specific messages,
(config)# no logging message message-number
the admin can “promote” the VMID to a different severity. This lets the admin set the VMIDs related to successful authentications and configuration changes to severity 3 rather than severity 5 or 6.
(config)# logging message message-number [level level]
Now logs originally set for severity 3, as well as the logs for successful authentications and configuration changes, are being logged within severity level 3. This eliminates a lot of logging overhead without dropping the data an organization is required to collect.
Tags: cisco, compliance, keywords: log management
In the belly of the whale…
I recall a story from infant school. It described a holy man being begged by frightened mariners during a storm to pray for calm waters. He refused, suggesting that it was better not to wait until the storm, but to have acted before the clouds gathered.
To a similar point, ‘feast or famine’ is a favourite phrase of mine. I use it to describe folly of all kinds. But it’s a great way to highlight a major organisational shortcoming too – the side-lining of known important activities in favour of short term pressures. This is a tactic everyone uses though, surely? Well, in the security field it’s not working and hasn’t worked for years.
“Little and often’ is another favourite. I use it to describe a more virtuous method. It seems that whether you’re seeking to keep fit, preparing for an important event or even keeping on top of expenses, it’s a phrase that describes desirable behaviour. For many organisations, security spending has been far more ‘feast or famine’ than ‘little and often’, certainly as long as I have been in the industry anyway. Could this be about to change?
It all used to be about compliance. Security-related expenditure, that is. As long as the compliance box was ticked, the CFO’s job was safe, and the operations team could avoid getting yelled at in review meetings. But look at the last three months – it seems like the highest profile, most trusted brands are haemorrhaging customer information, credit card details and intellectual property to hackers. I’m not using those terms licentiously either – RSA, Sony and even the X-Factor database have been compromised. Those three events alone could add up to nearly half a billion compromised records. Does this mean compliance measures are not working? Well, the recent Verizon report suggests that where breaches have occurred, an overwhelming percentage of the companies that should have been PCI compliant, weren’t. 89% in fact. But these recent breaches were all despite compliance systems in being place, which seems to increasingly be the case.
What does this mean in terms of brand confidence? Here’s an example. I spend a lot of money with Amazon annually. In fact, I transact with them twenty or thirty times a year. Their customer service is every bit as good as people say. But, do you think Barnes and Noble or Play.com would get my business if Amazon lost my credit card number? You bet they would. Maybe this is where security is at an inflexion point. Are we at the stage, where organisations have to make ‘pre-sale’ commitments to customers about the safety of their data? Would I move suppliers in favour of someone who offered guarantees as to the safety of my personal information? Maybe.
In any event, security is getting interesting again. Do we now work in a discipline which, rather than being a perceived cost and burden to an organisation, could quickly become a competitive differentiator? I can see it happening, but not while spending patterns are so ‘feast or famine ‘? Maybe it’s time to start bidding for security funding not just for compliance and risk mitigation, but as a way that organisations can improve customer confidence, retention and intimacy through cast-iron security guarantees.
This may sound like blue-sky thinking – particularly in the context of things like Advanced Persistent Threats (APTs). If a syndicate has enough time and resources, won’t they always find a way in? Not if you have the right resources to hand. Whether access to your systems has been socially engineered, or via a stealth APT that may have taken 6 months, a good logging solution is key. Pinpoint and exploit early warnings, and use targeted resources to take remedial action and mobilise defences quickly. Be warned though – feast or famine won’t work – this requires a little effort, often.
Tags: advanced persistent threats, compliance, network security, pci
IT Archaeology “Easy Access to Your Archived Logs for Historical Forensics”
I once lost a huge amount of data – the regular stuff such as photos and other useful files. A review of the logs with my SIEM product showed several disk failure messages. Had I only been able to make sense of the logs and known what they meant I could have saved all my data. Of course, while losing some files is inconvenient, what happens when the data that is lost is of a more critical nature, such as the log files that you may need to analyse in the future for forensic purposes or compliance? Now that I have a few more years of SIEM experience and have seen the alternatives, no one else, as far as I have seen, has executed on the concept of using log data for analysis and/or reporting like LogRhythm.
I work with Support and Professional Services at LogRhythm. A typical day at LogRhythm is one where I am reviewing tickets and a call comes in from a customer that goes something like this: “I am investigating an incident that took place 6 months ago. Is there a way I can achieve this with LogRhythm? I have so far tried restoring data from old backups and used SQL queries, command line tools and varying degrees of imagination to try finding some of the data relating to a specific user and systems. I have also logged into my Domain Controllers but they only keep up to a week of data at most.”
Fortunately I’m able to respond with: “Of course you can. Providing that you still have the Log Data available for that time period, you can use the SecondLook feature to recover any log data you want.”
It’s interesting to me that one of LogRhythm’s most useful forensics tool is one of the more ‘unknown’ features to quite a few of our customers. In LogRhythm speak this capability is known as the SecondLook archive restoration wizard, and it makes a huge difference for someone tasked with performing a forensics investigation – like the one I just mentioned.
LogRhythm’s SecondLook wizard allows you to retrieve log data from any archive files, such as those stored directly on your LogRhythm Server, or off the box on a SAN or NAS. It allows you to bring this back to a separate database and make the data available for investigations and reporting. Since the archived data is digitally signed with a cryptographic hash, it can also report if any modification or deletion of data has taken place, maintaining the digital chain-of custody that most of our customers require.
To use SecondLook all you need to configure is a new database instance called the Recovered Archive Database (RADB), which is used for analysis and forensics on data that is no longer kept online.

Then you use the SecondLook wizard to bring back any archived data that matches your search criteria into the RADB. Once it’s there, you can easily run an investigation against this database.

Don’t get me wrong, backups are very important, especially considering my data loss scenario, where a lot more than log data was lost. However, when it comes to making long term log data available for investigation and reporting on what happened several months ago, you can’t beat SecondLook.
Tags: compliance, log management, logrhythm, siem
Compliance buys the steak, but where is the sizzle?
Another meeting or WebEx demo is scheduled – things are busy for me six months in as Sales Engineer for LogRhythm in the UK. I dial into the conference call and off we go. The first question that normally gets asked by one of my enthusiastic sales colleagues is “what’s the driver for the project…?” To date the answer is usually “compliance“.
I’ve worked with enterprise networks for over 10 years now and was responsible for designing, deploying and managing a large network for a leading Managed Security Services provider. When I designed the network, I paid no attention to log and event management. I knew that each of the products and technologies created logs and had their own management interface to allow me to view that information if needed. From what I’ve seen, this isn’t an uncommon approach. It then happened……
… Friday night @ 17:00hrs, my phone rings and it’s one of the sales managers on the phone: “Hi, can you create a report showing when John Doe has logged into the network over the past two weeks?” Ok, this isn’t too much of a task for me I think, I can simply log into the domain controller and take a look at the security logs, export the information to excel, manually edit it and create a report. Then the same sales manager asks “I also want to know what websites John Doe has visited whilst logged into the corporate network. Oh, and can you tell me if they have also logged in remotely over the VPN? If I can have the reports on my desk Monday morning, that would be good.” All of a sudden the fairly simple task becomes more complicated and will require the use of various different GUIs, tools and lots of my weekend!
…Back to the demo: As I walk through the console showing the customer how easy it is to run an investigation against any or all of the log sources, showing how to use the common events and classifications to apply filters (Origin Login = John Doe, Classification = Authentication Success) to the log data that LogRhythm has enriched and normalized, I then show how easy it is to use the displayed data

and create a graphical report.
I continue to demonstrate the power of tail in a troubleshooting or activity monitoring scenario and apply a filter showing URL and Origin Login = John Doe and we sit there in real-time watching the user’s activity. It’s about this point that the pin drops.

Yes the driver might be Compliance, but it’s the additional operational features and visibility that LogRhythm provides that gets the technical operations team excited and actually sells the product more often that compliance on its own.
I wish I had paid more attention to my SIEM requirements when I designed the MSSP network all those years back. If I had I would have made it home much earlier that Friday night!
Tags: compliance, log management, network security, siem
LogRhythm wins "Innovator of the Year" from SC Magazine. "This is not your father's log manager."