Thursday, September 02, 2010

LogChat Podcast 1: Anton Chuvakin and Andrew Hay Talk Logs

"LogChat" Podcast is born! Everybody knows that all this world needs is a podcast devoted to logs, logging and log management (as well as SIEM, incident response and other closely related subjects).

And now you have it - through the sheer combined genius of Andrew Hay and myself, Anton Chuvakin.

Administrative items first:

  1. We need a new name! We are not entirely happy with "LogChat" and, sadly, "LogTalk" is taken. Please suggest a name - if we pick yours, you get a free signed  copy of my "PCI Compliance" book.
  2. We will post the transcript, not just the MP3 file - in a few days. If you have ideas for a good/inexpensive transcribing service, we are all ears. I will try Amazon Mechanical Turk first, but it might not be good enough for a technical podcast.
  3. Please also suggest topics to cover as well - even though we are not likely to run out of ideas for a few years. Our first topic today is new log source integration - if it sounds boring...well...listen first/judge second :-)
  4. We plan for this to be a monthly podcast. So, the next one will happen sometime early October.
  5. Any other feedback is HUGELY useful. Is it too long? Too loud? Not enough jokes? Too few mentions of the "cloud"? Feedback please! Who knows...maybe there are more PCI books left in my secret stash and you too will earn that glorious prize for the most useful piece of feedback  :-)

And now, in all its, glory - the podcast: the link to MP3 is here [MP3].

Enjoy the log chat!

Wednesday, September 01, 2010

Fun Project Honeynet Log Challenge: Log Mysteries

Project Honeynet just released its latest Forensic Challenge 5 - Log Mysteries. It is based on logs from a compromised virtual server and requires quite a bit of digging through messy log data.

The Challenge:
Analyze the attached sanitized_log.zip [A.C. – get the logs here] and answer the following questions:

  1. Was the system compromised and when? How do you know that for sure? (5pts)
  2. If the was compromised, what was the method used? (5pts)
  3. Can you locate how many attackers failed? If some succeeded, how many were they? How many stopped attacking after the first success? (5pts)
  4. What happened after the brute force attack? (5pts)
  5. Locate the authentication logs, was a bruteforce attack performed? if yes how many? (5pts)
  6. What is the timeline of significant events? How certain are you of the timing? (5pts)
  7. Anything else that looks suspicious in the logs? Any misconfigurations? Other issues? (5pts)
  8. Was an automatic tool used to perform the attack? if yes which one? (5pts)
  9. What can you say about the attacker's goals and methods? (5pts)

Bonus. What would you have done to avoid this attack? (5pts)

Go get the challenge here and get to solving it – you have about a month. And, yes, there will be prizes too!

Finally, if you really want to make me happy (hehe...who’d want that? :-)), please invent a new approach while solving the challenge.

Possibly related posts:

Tuesday, August 31, 2010

Another Fun SIEM Whitepaper

As promised, here is another detailed SIEM whitepaper called “A Pragmatic Approach to SIEM: Buy for Compliance, Use for Security” that I wrote for a great team at Tripwire earlier this year.

TW_WP

“While recent economic troubles might have something to do with it, many organizations today seek to only do a bare minimum of security. To be more precise, they try to do what they think is the bare necessary minimum. Their perception that security “due diligence” can be reduced all the way down to the level prescribed by regulations, such as PCI DSS, is more common than ever today. All too common result of this thinking is security breaches and other damaging events.

This trend has affected many security safeguards, and SIEM and log management are hard hit by this as well. It is very common to deploy these technologies in order to satisfy the compliance check box. In this paper we will analyze this trend and provide useful guidance for getting value out of SIEM and log management tools while focusing on protecting systems and data – and not simply on checking the box.”

Get the paper here.

Possible related posts:

Friday, August 27, 2010

CEE Architecture Overview FINALLY Out!

The future of logging is finally here! Common Event Expression (CEE) team releases CEE Architecture Overview [PDF] for public comments. HUGE thanks to MITRE side of team for finally clearing all the hurdles and releasing “our baby.”

The Common Event Expression (CEE™) Architecture Overview document defines the structure and components that comprise the CEE event log standard. This architecture was developed by MITRE, in collaboration with industry and government, and builds upon the Common Event Expression Whitepaper. This document defines the CEE Architecture for an open, practical, and industry-accepted event log standard. It provides a high-level overview of CEE along with details on the overall architecture and introduces each of the CEE components including the data dictionary, event taxonomies, syntax encodings, and profiles. The CEE Architecture is the first in a collection of documents and specifications, whose combination provides the necessary pieces to create the complete CEE event log standard. 

We encourage community members to offer feedback on this document on the CEE
Email Discussion list. You may also contact us directly at cee@mitre.org.

Again, the document is at: http://cee.mitre.org/docs/CEE_Architecture_Overview-v0.5.pdf

The day we were working towards for nearly five years (!) has finally come and more of CEE is revealed to the world! Of course, detailed specifications are still in development and we will release them when they are ready for public review.

Possibly related posts:

Tuesday, August 24, 2010

To Those Escaping from Sinking SIEM/Log Management Vendors

As I am hearing rumors about some sinking (and some sunk) SIEM/log management ships, here is a special “public service” announcement to those affected by the disasters.

Don’t despair!

Quality vendors in this space are hiring like crazy, especially if you are a good Field Engineer (example) or Professional Services (example). Check out other SIEM and log management vendor sites as well, a lot of field hiring and some HQ hiring is going on as we speak.

And, if you happen to be a customer of one of those unfortunate vendors, well… pick better next time :-) Oh, one more tip: security vendors are not a reliable source of information on “security vendor longevity.” You will get wildly-crazy over-estimates (about self) and minblowingly-insane under-estimates (about competitors)…

Possibly related pots:

Enhanced by Zemanta

Monday, August 23, 2010

Silly Compliance Poll

OK, some of you would say that I have weird hobbies, like writing books about  PCI DSS. image

In any case, just for fun I am running this poll on compliance here. Please respond – violently is OK, if compliance brings this up in you :-)

Enjoy!

Possibly related posts:

  • Old posts with fun polls and their analysis.

Sunday, August 22, 2010

CEE Update – Aug 2010

Reposted (from here) for those who don’t monitor public Common Event Expression (CEE) log standard effort.

“First of all, let me answer the question that is in all of your heads: No, CEE is not dead... After a slow start, the work pace has picked up over the past couple of months. I apologize for the extremely long delay in posting any details regarding the state of CEE.


The CEE Board [that’s us – A.C. :-)] has been working on bringing the CEE Dictionary, Taxonomy, and Syntax requirements together. We have drafted specification documents detailing the CEE Architecture as well as the initial Dictionary and Taxonomy specifications. These documents are the first of the CEE v0.5 (previous versions were internal) document series and have already been shared with some of you for your feedback. We are waiting for the final authorization before they are posted to the CEE website for your review.

This authorization is expected to be granted next week. A follow-up e-mail will be sent to this discussion list as well as the CEE Announce list notifying you that the documents were posted along with the URL where said documents may be obtained. It is important to note that these are only the first iterations of many. We need your help in improving CEE.
 

In addition to helping critique and improve the CEE documents, we are also requesting your help in building and improving the CEE Use Cases. Within the next week or two, you will also receive the beginnings of a list of CEE Use Cases for review.”

Sign up for the public CEE list to see more. Meanwhile, the effort for log standardization makes another step!

Friday, August 20, 2010

Log Math

100,000 log messages / second x 300 bytes / log message ~ 28.6 MB
      x 3600 seconds  ~ 100.6 GB / hour
            x 24 hours ~ 2.35 TB / day
                  x 365 days ~ 860.5 TB / year
                        x 3 years ~ 2.52 PB

Oops! Now you know what is a petabyte.
And, BTW, you also now what is a trillion – of log messages.

Wednesday, August 18, 2010

Brief PCI Council Interview in Regards to PCI DSS 2.0

Everybody knows that PCI DSS 2.0 is coming! The Council released a summary of changes for version 2.0 [PDF] to be released in October 2010. Council folks have granted this brief interview to Security Warrior Blog; it is provided below in its entirety:

 

Q1: As promised, the changes to PCI DSS are minor. Are you worried that since the next edition will come in 2013, both technology and threat landscape will change way too much and DSS will lose its relevance over time?

PCI Council Answer 1: The Standard is maturing and is increasingly being adopted globally, that's part of the reason why there are no new requirements  in DSS 2.0. Nonetheless, we always have in place an errata process that allows us to add elements or requirements to the standards as necessary. It is important to note that in the years that the standards have been in effect, there has never been a specific threats that has required this. [emphasis by A.C.]

[A.C. – I am sure the highlighted bit will rile a lot of noisy security folks with minimum knowledge of the payment industry, but, upon some thinking, I actually tend to agree with it - mostly. The issue is not with “requirements are stale”, but with merchants not doing this stuff. Daily log reviews are MANDATORY for PCI DSS compliance (see Req 10.6). Are they ALL doing it? Ha. And people still fall victim to passwords guessing en masse – like its 1983. Even future “PCI in the cloud” is fairly well addressed by Req 12.8. So please can this “threats are dynamic” snivel…]

 

Q2: Does Council plan to launch any studies on the effectiveness of "the new PCI DSS" vs today's cyber attacks against payment card data?

PCI Council Answer 1: While we have no plans for an official study, we do receive feedback and public forensic reports, like the recent Verizon Data Breach report that allow us to review forensic data gathered globally. [link added  by A.C.]

 

Q2: Will there be any changes to Prioritized Approach to PCI DSS document in light of PCI DSS changes?

PCI Council Answer 3: Not at this point, but the new DSS does allow, on a merchant by merchant basis, a certain degree of a risk-based approach during their assessments.

[A.C. – this means that “implementation first, policy last” thinking will stay in. Intuitively, I get it – policies on their own don’t stop loss, while removal of PAN storage does – but I expect a lot of whining over this one as well]

 

Q4: Does Council plan any additional implementation guidance along the lines of wireless guidelines to help merchants comply with PCI 2.0?

PCI Council Answer 4: At some point, we will be releasing a similar set of guidelines on Bluetooth deployments, similar to the Wireless Guidelines.

There you have it. And we wouldn’t even have to update our PCI book much :-) Go PCI 2.0!

Tuesday, August 17, 2010

SIEM-related Job: Principal SIEM Consultant

As a favor to yet another friend, I am posting yet another SIEM-related job.

Job Description

A Principal Security Consultant at Vigilant is expected to leverage his/her extensive technical abilities to provide innovative, pragmatic and business-focused security solutions for our customers. Principal Security Consultants report to the Director of Services Delivery, and are expected to work in the capacity of a Vigilant Project Managers on multiple, concurrent engagements to architect and deliver a variety of solutions, in such functional areas as Security Information / Event Management (SIEM), Security Architecture & Design, and general Security Assessments. It is expected that the Principal Security Consultant will be a mentor within the Professional Services team, and will provide expert advice and guidance to partners and newer Vigilant consultants. Applicants who reside in the NY Metro area and Washington DC area are encouraged to apply.

Skills

Analytical & Technical Skills:
• Expert knowledge of SIEM products (ArcSight, Novell Sentinel, RSA enVision, etc.)
• Ability to design complex, enterprise-scale network security architectures
• Extensive knowledge in the use and configuration of relational databases, including Oracle and SQL Server
• Expert knowledge in the use of Unix (Solaris/Linux) and Windows Server Family (NT/2000)
• Extensive experience with Intrusion Detection Systems, Firewalls, Proxy Servers, Antivirus, NAC, or other network security infrastructure
• Familiarity with the integration of 3rd-party applications (ETL tools, data mining, business intelligence products)
• Ability to analyze complex issues for impact and alternative solutions, making logical decisions based on overall product objectives
• Ability to prioritize tasks and manage time efficiently. High level of self-initiative and self-motivation.

Full info and how to apply is here.

More SIEM jobs from Vigilant in the NYC area are here.

Possibly related posts:

New SIEM Whitepaper on Use Cases In-Depth OUT!

A lot of people talk about “SIEM use cases” (example), but few describe them in depth, complete with instructions on how imageto actually solve the problems and actually do each use case, using a particular SIEM tool. Here at Security Warrior Consulting, we are all about DOING, not just TALKING :-)

With this introduction, I am presenting a new detailed SIEM whitepaper that I wrote for the RSA enVision team.  “This paper will help jumpstart SIEM use process and highlight common SIEM usage scenarios for organizations of all sizes. It will also explain how to operationalize the SIEM tool and utilize it for many security use cases and scenarios, from Web site threats to security incident response. Specific examples from RSA’s enVision platform are used to illustrate the concepts in the paper.”
Here is an excerpt from one  use case from the paper:

Comprehensive firewall monitoring
(security + network)

Since the early days of SIEM technology, firewall log data
has been considered as one of the most useful and
commonly collected information sources.
Apart from allowing and denying connections to and from
the network, firewalls allow recording or logging of every
single connection denied or allowed by the firewall. An
example would be connections from the outside world to
the DMZ Web server, or connections by users inside the
company to their favorite social media Web site.
Analysis of such logs is extremely useful for security,
compliance and even operational purposes such as
network management, bandwidth management, etc.
For example, on the compliance side, PCI DSS, HIPAA,
NERC/FERC all have firewall logging implications. Firewall
logs are also extremely useful for incident response and
forensics since they can help identify the connectivity
pattern and serve as “poor man netflow.” On top of this,
firewall logs can be used to assess the health of the
firewall itself and to optimize the rule set performance.

Collection: comprehensive firewall log collection is
mandatory for this use case, and it is important to
remember that firewalls can record both failed and
successful connections through the firewall – both
types are essential for SIEM.
Grab the paper here [PDF]!

Another fun long whitepaper is coming soon … and it will be just as fun.

Possibly related posts:
Enhanced by Zemanta

Monday, August 16, 2010

CloudAudit Delivers – Cloud Compliance Maps

CloudAudit delivers it’s first batch of cloud compliance specifications. Quoting from the announcement:

“The CloudAudit initial distribution features five elements:

1) The CloudAudit normative specification in .txt format [cloudaudit-specification_draft.txt]
2) The CloudAudit CompliancePacks archive of .xls files which map controls/control objectives to namespaces based upon the Cloud Security Alliance Control Matrix [cloudaudit-compliancepacks.zip]
3) The CloudAudit namespaces archive which represents a complete CloudAudit directory tree representation of all CompliancePacks    with placeholder index.html/manifest.xml created in each directory stub [cloudaudit-namespaces.zip]
4) The CloudAudit Python script pack which automates the creation of the CloudAudit namespaces above  [cloudaudit-namespace_creator.zip]
5) A README.txt file [this content]”

and

“The CompliancePacks map control objectives to specific namespace entities which are contained below and feature NIST SP800-53, PCI DSS, HIPAA, ISO27002 and COBIT compliance frameworks.  Ultimately these directories are where a Cloud Provider will store and secure the assertions and supporting materials related to each compliance framework or assertion.” [<- the bold part is kinda the whole point :-) A.C.]

Grab the mammoth itself here [ZIP].

Enjoy!

Wednesday, August 11, 2010

Pathetic Analytics Epiphany!

As some of you know, I have been doing SIEM and log management for more than 9 years already. Nine years of looking at them logs is a long time, lemme tell you  :-) image
And that 86% of cases where intrusion evidence was present in logs (see Verizon 2010 Breach Report) just sent me down into cold rage. This is freakin’ year twenty-ten! Why are people STILL not looking at their logs?!! Not even monthly especially where daily is mandated (see PCI DSS)?! Are they that mind-blowingly stupid?! Do they love to live on the bloody edge, perhaps? Do they enjoy being violently penetrated and not even enjoy it, purely for masochistic purposes? I read some blog posts which basically expressed the same rage (example), and my rage just became The Epic Log Rage.
And while consumed by this rage, I had an epiphany! End-users are not really the ones to blame - not that much. Nobody can be blamed for not wanting to ‘grep’ a 245GB log file… I think :-)
Our log analysis tools are simply too pathetic. Think about it - they are!!!
Why is “empty search window” and “overly complicated correlation rule builder” represent the state of the art of log analysis after nearly 20 years of development in this field?! Why do we have to dig for log insights like fucking truffle hunting pigs?
image
Further, yesterday I was trying to explain the state of the art of log analysis to a client (who looks to use his cool  new technology for log analysis and SIEM), and I felt embarrassed to admit that, yes, “search” and “rules” are indeed the state of the art.
In other words, most of the analysis burden is on the tool USER BRAIN, not on the TOOL. They looked at me like I just wasted 10 years of my life, writing regexes and otherwise being a stupid monkey. Even things like profiling/baselining (example) or simple – and I mean SIMPLE – data mining (example, details) mostly stay on research drawing boards for ages.
So, I can talk about unsupervised learning, associative rule discovery and natural language processing (the other NLP) for logs as well as the next guy (and maybe better), but the tools you can buy just don’t have that shit. They have “compliance reports” [deep insight alert… NOT :-], “empty search window” and “learn what CustomInteger17 means and then you can write your very own correlation rule…that will function…maybe” while a simple Netflix movie selection triggers more brainpower on the backend than is available in all SIEM product combined…
To conclude, I have a suspicion that it is likely that in the near future all SIEM tools magically turn into electric typewriters.
P.S. My dear vendor friends and colleagues, don’t take offense! I still love you. We all just need to work and think a little harder – that’s all :-)
P.P.S My dear friends in academia, please DO take offense! Most log analysis research I’ve seen over the last 10 years is …mmm… not very practical. Get some real logs and get thinking!

Tuesday, August 10, 2010

“How to Do Application Logging Right” Paper OUT!

Just wanted to highlight another useful resource on logging: "How to Do Application Logging Right” by Gunnar Peterson and myself. Following on our previous IEEE paper (here [PDF]), we explored application logging from a developer's perspective. As Gunnar already pointed out, “audit logs are one of the quick, dirty and cheap things that can improve enterprise security.”

Here is a fun except:

“Organizations have finally gotten network device logging and—to
some extent—server logging under control. However, after getting
used to neat Cisco Adaptive Security Appliance or other firewall
logs and Linux “password accepted” messages, security incident
investigators trying to respond to the next wave of attacks
have been thrust into the horrific world of application logging.”

and

“We can start by establishing  criteria for good security audit logs (which we just call “logs” from now on). […]  On the basis of the six Ws, the following list [see paper] provides a starting point for what to include [in each application log message]”

and

“Software architects and developers must “get” logging; there’s
no other way. This is because infrastructure logging from network
devices and operating systems won’t cut it for detecting
and investigating application-level threats. Security teams will need
to guide developers and architects through useful, effective logging.”

Grab the paper here [PDF] and enjoy!

And, Raffy, you owe me another beer for “We thank Raffy Marty of Loggly for his thoughtful review of the draft article.” :-) In fact, I think me using the word “thoughtful” here justifies “beer+2”…

Possibly related posts:

  • IEEE

Friday, August 06, 2010

Updated With Community Feedback SANS Top 7 Essential Log Reports DRAFT2

Thanks for overwhelming community response (here, here, here, and separate blog posts here and here and I might have missed a few places too). The list has grown and is on the verge of becoming unwieldy and not “top” and “essential” so I am about to close the comment period, write up the doc and send it to SANS to update the legacy SANS Top 5 Log Reports [PDF].

Any last second thoughts before I document this baby? Any smokin’ hot log reports to add?!  Also, anything I should take OFF the list for not being “top” and “essential”?

 

1. Authentication and Authorization Reports

a. All login failures and successes by user, system, business unit – must have login success logs, not just failure!

b. Login attempts (successes, failures) to disabled/service/non-existing/default/suspended accounts

c. All logins after office hours / “off” hours

d. Users failing to authentication by count of unique systems they tried

e. VPN authentication and other remote access logins (success, failure)

f. Privileged account access: logins, su use, Run As use, etc (success, failure)

g. Multiple login failures followed by success by same account – needs to have correlation for that

2. Change Reports

a. Additions/changes/deletions to users, groups – even a trend on user additions across systems would be useful

b. Additions of accounts to administrator / privileged groups

c. Password changes and resets – by users and by admins to users

d. Additions/changes/deletions to network services

e. Changes to system files – binaries, configurations – likely needs a list to run

g. Changes in file access permissions

h. Application installs and updates (success, failure) by system, application, user

 

3. Network Activity Reports

a. Log volume trend over days – watch for both drops and increases in logging levels on systems

b. All outbound connections from internal and DMZ systems by system, connection count, user, bandwidth, count of unique destinations, hour of access (focus on “off hours”)

c. Top largest file transfers (inbound, outbound) OR Top largest sessions by bytes transferred

d. Web file uploads to external sites - based on proxy logs

e. All file downloads by content type (exe, dll, scr, upx, etc) and protocol (HTTP, IM, etc)

f. Internal systems using many different protocols/ports

g. Top internal systems as sources of multiple types of NIDS, NIPS or WAF Alerts

h. VPN network activity by user name, total session bytes, count of sessions, usage of internal resources

i. P2P use by internal systems

j. Wireless network activity

i. Rogue AP detection

ii. Wireless network access by user

iii. WIDS/WIPS alert activity

4. Resource Access Reports

a. General

i. Access to resources on critical systems after office hours / “off” hours

b. Web

i. Top internal users blocked by proxy from accessing prohibited sites (malware sources, pornography, etc)

c. File

i. File, network share or resource access (success, failure) - for specific audited resources

d. Database

i. Top database users - excluding known application access

ii. Summary of query types - excluding known application queries

iii. All privileged user access

iv. All users executing INSERT, DELETE commands - excluding known application queries

v. All users executing CREATE, GRANT, schema changes, etc

vi. Database backups

e. Email

i. Top internal email addresses by count of messages, byte volume

ii. Top internal email addresses sending attachments to public/hosted addresses

iii. All emailed attachment content types, sizes

iv. All internal systems sending mail – excluding known mail servers

5. Malware Activity Reports

a. All systems with AV events by user, system name, time trend

b. Detect-only events from anti-virus tools (leave-alones)

c. All anti-virus protection failures (crashes, unloads, update failures, etc)

d. Internal connections to known malware IP addresses – a public blacklist needed

6. Failures and Critical Errors

a. Critical errors by system, application, business unit

b. System and application crashes, shutdowns, restarts

c. Backup failures

d. Capacity / limit exhaustion - memory, disk, CPU, etc

7. Analytic Reports – Mostly Using “Never Before Seen” (NBS) aka “NEW Type/Object” Analysis = also add “rarely seen” / OSO / “bottom X by …”

a. NEW (NBS) Log message types / event types

b. NEW (NBS) Users authenticating successfully

c. NEW (NBS) Sources that connected to systems using privileged accounts

d. NEW (NBS) Internal system connecting to external systems

e. NEW (NBS) External IPs connecting to NEW Entry Points – not sure how to collect this

f. NEW (NBS) Ports accessed on internal systems

g. NEW (NBS) HTTP request types

h. NEW (NBS) Downloaded/uploaded content types

i. NEW (NBS) Query types on databases

 

More last-second comments? If not, I will be adding documentation for all report examples and submitting it to SANS for distribution.

Also, if you commented, please let me know if you do NOT want your name in the credits. Default:  you will be mentioned as valuable contributor as long as your contribution was, you know, valuable :-)

Possibly related posts:

Enhanced by Zemanta

Wednesday, August 04, 2010

Verizon Breach Report 2010 OUT!

Belated reading of Verizon DBIR 2010. My favorites:
image
79% of victims subject to PCI DSS had not achieved compliance” [close to what I suspect the reality is – a lot of organizations did try to ‘fake their way’ to PCI compliance. Hopefully now Bob’s point about ‘not compliant at the time of the the breach’ will make more sense – A.C.]
Because fraud alerts are the leading method of discovering breaches, it stands to reason that many breaches could occur without anyone being the wiser if the criminal decided it was in his best interest to be patient“ and “We find it more than a little ironic that the most effective way of detecting data breaches is for the perpetrator to fraudulently use what was stolen.” [every time I read “fraud is the leading method of breach discovery”, I feel sad. To me this means either most organizations are negligent, or our security technology is crap. Or both :-)]
I am not touching the whole insider vs outsider debate again; it just smells. Read the report and forget the “80/20 myth.” Think about it though: every organization has 1-100,000 insiders (=employees, partners, contractors, etc), but there are possibly millions of criminal outsiders… Given how porous many networks are, who do you think will steal more?
“incredible 97% (!) of the 140+ million records were compromised through customized malware across the Verizon-USSS caseload.” [toss the AV, finally? – A.C.]
The use of stolen credentials was the number one hacking type in both the Verizon and USSS datasets, which is pretty
amazing when you think about it.”
“We’ve observed companies that were hell-bent on getting patch x deployed by week’s end but hadn’t even glanced at their log files in months.”  [given that password guessing – seen in logs – trumps vuln exploitation by such a wide margin, this should change. Will it? – A.C.]
“The security media hype machine would like us to believe that we’re all Targets of Choice [which is ‘cool’ and not Targets of Opportunity which is silly – A.C.] and there’s nothing we can do to stop the new [insert whatever you like here] threat. This simply isn’t true and is not a healthy line of reasoning for security management.”  [indeed, ‘APT is for everyone’ message is pretty stupid. If your passwords on external routers are something like ‘password’, you have a long task list to go thru before ‘APT’ shows up – A.C.]
Breach discovery bar chart on the right is “The Saddest Picture Ever (TM)” :-) No comment really.image
“It cannot be a pleasant experience to learn that the six months of log data you’ve been collecting contained all the necessary indicators of a breach. It is, however, a common experience. We consistently find that nearly 90% of the time logs are available but discovery via log analysis remains
under 5%
.”
“In the 2009 DBIR, we reported that event monitoring and log analysis, which should be the doyen of detection, successfully alerted only 6% of breach victims. This year that figure has dropped—yes dropped—to 4%. Of that 4%, log analysis lead to the discovery of a handful of breaches while intrusion detection systems identified only one.” [‘Richard, IDS really is dead’ :-) or The Second Saddest Fact in the report - A.C.]
“Change your approach to event monitoring and log analysis: A quick review of a few findings from this report will set the stage
for this one. 1) In most attacks, the victim has several days or more before data are compromised. 2) Breaches take a long time to
discover and 3) when that finally happens, it usually isn’t the victim who finds it. 4) Finally, almost all victims have evidence of the
breach in their logs
.” [this, BTW, reminds us that ‘detection within days’ is darn right close to ‘real-time’ for most organizations… – A.C.]
Get full report here.
Enjoy!

Monday, August 02, 2010

Monthly Blog Round-Up – July 2010

Blogs are "stateless" and people often pay attention only to what they see today. Thus a lot of useful security reading material gets lost.  These monthly round-ups is my way of reminding people about interesting blog content. If you are “too busy to read the blogs,” at least read these.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts/topics.

  1. “Top5 SANS Log Reports Update DRAFT” finally beat the previous champion of a few months “Simple Log Review Checklist Released!” In a few days, I will post the results of a community effort to refine the new SANS Top 8 (!) Log Reports…stand by.
  2. Career posts somehow always get top scores automatically and “Skills for Work vs Skills for Getting Hired” is no exception. Just as its predecessor, “Myth of an Expert Generalist”, it got on my monthly Top 5 posts immediately, was featured on Reddit.com, etc, etc.
  3. How Do I Get The Best SIEM?”, a companion to “On Choosing SIEM“, went to the top like lighting a few months ago and stayed there this month. If you are thinking of getting a SIEM or a log management tool, check them out and also look at related resources at the end of these posts.  “The Myth of SIEM as “An Analyst-in-the-box” or How NOT to Pick a SIEM-II?” and ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” also stay at the top – it seems like smaller organizations are looking at deploying SIEM and log management and there is a lot of interest in simple guidance on this.
  4. Next up are my notes from University PCI DSS workshop where I delivered a keynote: “My Best PCI DSS Presentation EVER!” (the infamous “compliance kitten” quotes comes from here)
  5. The report from HITB 2010 Amsterdam conference which I opened with a keynote “Security Chasm” is also on the monthly top list – “HITB 2010 Amsterdam Awesomeness.”

Also, below I am thanking my top 5 referrers this month (those who are people, not organizations). So, thanks a lot to the following people whose blogs sent the most visitors to my blog:

  1. Michał Wiczyński
  2. Raffael Marty
  3. Dancho Danchev
  4. Walt Conway 
  5. Cédric Blancher

 See you in August; also see my annual “Top Posts” - 2007, 20082009!

P.S. Watch for a fun post tomorrow, releasing a new SIEM whitepaper that I wrote for a client.

Possibly related posts / past monthly popular blog round-ups:

Thursday, July 29, 2010

Log Awesomeness – On August 19!

As far as awesomeness is concerned  [and I am a big student of it :-)], this is full of it. BrightTalk Log Management Summit promises to be as awesome as logging events go... Here is an agenda:

WHEN: Thursday, August 19, 2010, attend live online throughout the day or afterward on-demand

HOW: Register Now: http://www.brighttalk.com/r/vbf

TOPICS AND PRESENTERS:

  • “Log Standards & Future Trends” by Dr. Anton Chuvakin, Principal, Security Warrior Consulting
  • “Leveraging Logs, Information and Events” by Derek Brink, VP & Research Fellow for IT Security, Aberdeen Group
  • “Log Visualization in the Cloud” by Raffael Marty, Chief Logger, SecViz.org <– how come they don’t mention Loggly here?
  • “The Integration Lifecycle: Loving Long Logging Lifecycles” by Andrew Hay, CISSP, Senior Analyst, Enterprise Security Practice, The 451 Group <- high chance for an awesomeness boost from Andrew!
  • “Best Practice and Approaches for Log Management” by Ritesh Singhai, Senior Security Engineer, SecureWorks
  • “Delivering Value from SIEM” by Chris Burtenshaw, Information & Technology Risk Manager, Deloitte

Enjoy! And “see” you there on August 19th.

Possibly related posts:

Enhanced by Zemanta

Monday, July 26, 2010

Skills for Work vs Skills for Getting Hired

Given the amount of attention my previous security career post gathered (“A Myth ….”), it is time for a new one. Some of it is inspired by Source Boston 2010 mentoring panel, a gift that just keeps on giving (BTW, I signed up as a mentor with that new project, InfoSecMentors).

So, let’s talk about security skills that you can prove, skills that you need for a job and skills that will pass HR filters. It shocks me – to put it mildly – that these three are often completely different – and not even overlapping.

Which ones do you need to develop? Should you spend time writing papers, hacking code or reading up on 10 domains of “see-bee-kay”? Should you get good at something that will not be immediately obvious to everybody (like reversing malware) or spent time doing something visible (like writing papers about malware without having first-hand knowledge of how it works)? Should you choose sexy esoteric area of security, get really good at it – and then notice that nobody wants to hire you for that – with the possible exception of a Russian crime syndicate? :-)

While it is extremely tempting to bark “All of them!” and stop right there, the reality seems more complex to me, as it almost always is.

  • Skills that help pass HR filters (and especially certifications like “see-sssss-ph”) sure seem important as you won’t even have a chance to get to using your other skills aka be hired – unless you are a master-ninja-networker! By the way, buzzword - loading your resume is not about skills - it is about a socially acceptable form of lying: TCP/IP, UDP, ICMP, BGP, IDS, IPS, W3C, CIFS, WAF, DLP, GRC, SIEM, NAC, IAM, SNMP, SMTP, POP3, HTTP, NASL, IPv6 … ASS :-)
  • Skills that will help you do the job obviously vary depending on what job you have in mind. For most entry- and mid-level security roles, these skills are technical (sorry, Mssrs Security Policy Writers). From log analysis to IPS tuning to firewall management to web application scanning, the range is broad and you need to choose.  You can pick an area and then go really deep; however, it is worthwhile to try not to pick “typewriter repair” as an area of specialization :-) Fortunately, since none of the security problems we ever faced have been solved yet, choosing wrong is very hard. If you are still lost, pick application security or pentesting. These are not going away – EVER!
  • Skills that are easy to prove - typically via a multiple choice test - is another interesting set: some technical skills (such as knowledge about what is in TCP/IP header) are easy to test, while others (such as an ability to do web app penetration testing) are extremely hard to validate. I guess social engineering is an ultimate “unprovable” skill, while knowledge about how to configure a Cisco router is easier to prove. BTW, I’ve met some “Cisco Gear Master Magicians” whose skills bordered on divine – they can literally get that box to do anything.

And if I were to give some advice on this that I wish I received when I started in security, I’d say focus your energies like this:

  1. Put most of you energy in developing skills that will be most useful at work – work you do at your current job or the one you dream about (aka your next job :-)) As I said above, it is more likely that these skills are technical.
  2. However, balance the time you spent practicing technical skills that are simply fun for you with the ones that are easy to prove to potential employees. Let’s call them “visible skills.”
  3. Severely limit the time you spent on developing skills just to pass HR filters – instead get better at networking! Darn, even Twitter skills are better than practicing your daily laps in alphabet soup like the mess above.

To figure out that point, I once asked my wise mentor “Why do you still run /bin/bash, awk around and install Fedora, after you wrote three books, sold a company, gave a dozen keynote speeches and run a profitable consulting business for many years?” He – wisely, of course – said: “So that I can be a sysadmin if shit hits the fan.” This line is still stuck in my head after many years!!

Otherwise, you risk being of those types who respond to an ad for “firewall admin, must have CISSP” and end up crashing the network, which is kinda sad. For example, for many years I’ve had this bizarre unconscious skepticism towards people whose main skill is to write security policy. Writing this post cleared my head as to why: a well-written security policy does EXACTLY nothing for security … unless it is implemented.

Finally, some folks reading this will say – “screw the skills, I just want to be an expensive loudmouth for hire.” OK. There are indeed a few who rose to such noble occupation… First, you have to slave away for many years doing something else – and then hope that eventually people will want to pay to listen to your rants. Second, you can join Gartner, still slave away for a few years – and then maybe people will pay for your “loudmouthery.” In both cases, you’d still need some “+5” to Luck :-) And then maybe you can be “a mercenary loudmouth.”

But this is likely a subject of another post.

Possibly related posts:

Friday, July 23, 2010

FINALLY! SANS SEC434 “The” Log Management Class (2-day version!) in Northern California on Sep 9-10, 2010

It will happen! My SANS SEC434 Log Management Class will be taught in in Northern California on Sep 9-10, 2010 in its never-before-seen extended 2-day version (with loads of cool hands-on log mangling exercises). The announcement follows below:

Log Management In-Depth: Compliance, Security, Forensics, and Troubleshooting
Thursday, September 9, 2010 - Friday, September 10, 2010

“This first-ever dedicated log management class for IT and security managers will cover system, network, and security logs and their management at an organization. We will start with the basics, like making sure that logs exist, and then go on to touch upon everything from managing log storage, to analysis techniques, to log forensics and regulatory issues related to logging.

In the beginning, we will cover various log types and provide configuration guidance, describe a phased approach to implementing a company-wide log management program, and go into specific tasks that IT and security managers need to be focusing on a daily, weekly, and monthly basis in regards to log monitoring.

A unique and comprehensive section that covers the hot topic of using logs for regulatory compliance, such as PCI DSS, will also be presented. Everybody knows that logs are essential for resolving compliance challenges; this class will teach you what you need to concentrate on and how to make your log management compliance-friendly.

The class will also touch upon various uses of logs for incident response, forensics, and operational monitoring. Common logging mistakes, learned from many years of working with logs, will also be explained.”

Class Location:

UC Davis
Room 1065, Kemper Hall, UC Davis
1 Shields Ave
Davis, CA
Web site: www.ucdavis.edu

The price is actually VERY reasonable.

Sign up … NOW! I mean it!! :-)

Possibly related posts:

Monday, July 19, 2010

SIEM-related Field Job: Western US

As a favor to another friend, I am posting this fun SIEM field job here:

TECHNOLOGY SALES SPECIALIST (PRESALES), Security Products

We are seeking an exceptional individual to serve as a presales technical expert in the sale of Novell Security Management products to a variety of clients throughout the US and Canada.”

“You will be the technology expert in the sales effort as a Novell sales team works with a variety of companies in positioning Novell ISM products.  While you are part of the sales team, your efforts will still be dedicated to technical tasks up to 75% of your time.”

Full details.

Possibly related posts:

Tuesday, July 13, 2010

SANS Top 5 Essential Log Reports Update!

Some of you remember the project started at SANS Log Management Summit 2006 called “SANS Top 5 Essential Log Reports.” You can still grab the old document here [PDF]. Recently, I volunteered to create a 2010 version of SANS Top 5 Log Reports.
With help from others [to be credited when the project is complete, but definitely with help from somebody named MJR :-)] and some research into past efforts, I have identified the report types and specific examples below as candidates for a new Top 7 Essential Log Reports list – and now I need your help!
Initially, I wanted people to vote for 5 out of the 7 candidates, but let’s do it differently: just comment on the list below (blog comments, your own blogs – please post a li here, email, twitter, etc) or suggest your own most useful, most popular log reports or even report categories. There is no reason why we can’t have Top 7 or Top N>7 useful log reports :-)

NEW PROPOSED Top 7 Essential Log Reports

Top Log Report Candidate 1. Authentication and Authorization Reports
a. Login Failures and Successes
b. Attempts to gain unauthorized access through existing accounts
c. Privileged account access (success, failure)
d. VPN Authentication and other remote access (success, failure)
e. Please add more reports you find useful!
Top Log Report Candidate 2. Change Reports
a. Addition/Changes/Deletions to Users, Groups and Services
b. Change to configurations
c. Application installs and Updates
d. Please add more reports you find useful!
Top Log Report Candidate 3. Network Activity Reports [used to be called “Suspicious or Unauthorized Network Traffic Patterns” in the old Top 5 list]
a. Top Internal Systems Connecting Through Firewall // Summary of Outbound Connections
b. Network Services Transiting A Firewall
c. Top Largest File Transfers Through the Firewall
d. Internal Systems Using Many Different Protocols/Ports
e. Top Internal Systems With NIDS Alerts
f. Proxy Report on File Uploads
g. Please add more reports you find useful!
Top Log Report Candidate 4. Resource Access Reports
a. File
i. Failed File or Resource Access Attempts
b. Database
i. Top Database Users
ii. Summary of Query Types
iii. SELECT Data Volume
iv. All Users Executing INSERT/DELETE Commands
v. Database Backups
c. Email
i. Top Internal Email Addresses by Volume of Messages
ii. Top Attachment Types with Sizes
iii. Top Internal Systems Sending Spam // Top Internal Systems Sending Email NOT Through Mail Server
c. Please add more reports you find useful!
Top Log Report Candidate 5. Malware Activity Reports
a. Top systems with anti-malware events
b. Detect-only events from anti-malware tools (“leave-alones”)
c. Anti-virus protection failures by type
d. Internal malware connections (all sources)
e. Please add more reports you find useful!
Top Log Report Candidate 6. “Various FAIL”
a. Critical Errors
b. Backup failures
c. Capacity / Limit Exhaustion
d. System and Application Starts, Shutdowns and Restarts
e. Please add more reports you find useful!
Top Log Report Candidate 7. Analytic Reports  [Mostly Using “Never Before Seen” (NBS) aka “NEW Type/Object” Analysis]
a. NEW (NBS) IDS/IPS Alert Types
b. NEW (NBS) Log Entry Types
c. NEW (NBS) Users Authentication Success
d. NEW (NBS) Internal Systems Connecting Through Firewall
e. NEW (NBS) Ports Accessed
f. NEW (NBS) HTTP Request Types
g. NEW (NBS) Query Types on Database
h. Please add more NBS or other analytic reports you find useful!

So, please help this project by commenting via whatever means!!!

BTW, I think I perused all the previous efforts to distill log reports (such as this one), but feel free to point me to such things as well.

Finally, if you are a SIEM or log management vendor, please consider supporting the resulting reports in your products – after they are finalized by the community and released by SANS.

Possibly related posts:

Wednesday, July 07, 2010

HITB 2010 Amsterdam Awesomeness

I just came back from Amsterdam where I presented my keynote "Security Chasm" at Hack In The Box 2010 conference European debut. Both the keynote and the entire conference were a lot of fun - but then again WTH do expect from an event in Amsterdam? Below are my notes from the event.

0701102016-00

It is worthwhile to note that I was the first speaker of the first day, which put some extra responsibility onto my shoulders. The main theme of my speech was that we have essentially two "securities" - one where people do paper risk assessments, "align strategy" and “enable business” and another where people actually deal with consequences of intrusions and other burning technical issues. You can read some notes from the audience here (and here) and live tweeting here.

hitb-key

Next I went to Fyodor Yarochkin presentation on Russian cybercrime called “From Russia with Love 2.0.” While lots of people speak about Russian cybercrime, Fyodor’s take was interesting and new (at least to me). First, did you know that most Russian malicious hackers face no ethical challenges - they think of what they do simply as "making money online?" For example, Fyodor reported that people were asking on one of the forums "Is it legal to Google for card numbers and then use them?" :-)  Along the same line, he does not think many of them are “professionals” - but simply people making some money on the side off “stupid rich foreigners” [A.C. – we are talking about you, dear merchants ignoring PCI DSS… :-)].  Despite all that, he did describe a lot of interesting bits of criminal infrastructure such as eBay-like site for selling stolen Skype accounts with online feedbacks (for assuring stolen account reliability, ya know) and “conversion services” for transferring money, say from WebMoney to PayPal.

The speaker also mentioned that the rumors of Russian political hackers are “greatly exaggerated” - by far the most are in it for the money (and, yes, you can hire some to further your political goals like blowing away Twitter for $80/day, but it doesn’t make them “political hackers”).  Another curious resource he highlighted was a complete tutorial for “making money online” - where to start if you are a complete amateur, barely know computers, but want to make money. Another fun bit was that he described how much DoS costs have fallen…

Now, the other part of his presentation was a description of his research tool for automatic intelligence gathering and analysis, complete with text mining, jargon conversion and language translation.

Another worthwhile speech that I would like to highlight was the second keynote by Mark Curphey - who “left” security a while back. It was so visual and hard to summarize that I probably won't do it justice here - just check his deck. It was about his “10 Crazy Ideas to Improve Security” such as “#2 stop human pattern matching” (ha, I wish we knew how to do that :-)) and “#3 community statistical analysis for security.” Audience comments are here.

Also, I went to the presentation by the author of Maltego analysis tool.  I have long been curious about the capabilities of this tool, and it seems like v3 will come with even more magic such as “named entity recognition ” (NER) which allows the tool to extract names of people and countries out of the analysis. And it might tell you who wins the 2010 FIFA World Cup … and be wrong about it :-)

As far as fun hallway conversation is concerned, I had a couple of very fun chats: one with Rop Gonggrijp about climate change and geopolitics and one with Mark Curphey on using agile for security (and security in agile software development)

Finally, presentation materials can be found here.  Videos are promised to be posted soon! Enjoy!

BTW, if you’d like to invite me to speak at your conference, please do so, but keep in kind that flying around and speaking does not pay the bills :-)

Friday, July 02, 2010

Monthly Blog Round-Up – June 2010

Blogs are "stateless" and people often pay attention only to what they see today. Thus a lot of useful security reading material gets lost.  These monthly round-ups is my way of reminding people about interesting blog content. If you are “too busy to read the blogs,” at least read these.

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts/topics.

  1. By a HUGE margin again, the #1 post this month is “Simple Log Review Checklist Released!” Grab our log review checklist here, if you have not done so already. It is perfect to hand out to junior sysadmins who are just starting up with logs. Another similar resource is in the works… If you are a vendor, you can also use it to market your logging awesomeness :-) - but you have  to keep the attribution to the authors.
  2. How Do I Get The Best SIEM?”, a companion to “On Choosing SIEM“, went to the top like lighting last month and stayed there this month. If you are thinking of getting a SIEM or a log management tool, check them out and also look at related resources at the end of these posts.
  3. Next up are my notes from University PCI DSS workshop where I delivered a keynote: “My Best PCI DSS Presentation EVER!” (the infamous “compliance kitten” quotes comes from here)
  4. How PCI Leads to DLP?” discusses the linkage between PCI DSS compliance and Data Leak/Loss Prevention/Protection (DLP) tools. And, no, PCI DSS won’t mandate DLP soon – but it doesn’t mean that you should not look at it for various PCI-related reasons.
  5. The Myth of SIEM as “An Analyst-in-the-box” or How NOT to Pick a SIEM-II?” and ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” stay at the top – it seems like smaller organizations are looking at deploying SIEM and log management and there is a lot of interest in simple guidance on this.

Also, below I am thanking my top 5 referrers this month (those who are people, not organizations). So, thanks a lot to the following people whose blogs sent the most visitors to my blog:

  1. Michał Wiczyński
  2. Raffael Marty
  3. Dancho Danchev
  4. Richard Beitlich
  5. Cédric Blancher

See you in July; also see my annual “Top Posts” - 2007, 20082009!

Possibly related posts / past monthly popular blog round-ups:

Friday, June 25, 2010

SANS Log Management Class in California?

This post is not just an announcement; it contains a BIG question to my readers, mostly in California and around.

As you know, I have authored a SANS Log Management Class (SEC434) which is almost out of beta and near production stage, after a few years of tuning and trial runs. We are thinking of teaching it in California during the second week of August 2010. Via this blog post, I wanted to get some quick feedback from my readers about how many might want to sign up for it. So, please just leave a comment here if you’d like to attend!

Also, I wanted to check whether anybody’s employer (a log management or SIEM vendor perhaps…) would be willing to provide a venue to teach a class. We just need a room with a projector, nothing fancy. In exchange for that, SANS will give you some free attendance seats for the class. So, drop me an email, DM or something, if you’d like to take this opportunity.

The updated information on the class follows below:

“This first-ever dedicated log management class teaches system, network, and security logs, their analysis and management and covers the complete lifecycle of dealing with logs: the whys, hows and whats.

You will learn how to enable logging and then how to deal with the resulting data deluge by managing data retention, analyzing data using search, filtering and correlation as well as how to apply what you learned to key business and security problems. The class also teaches applications of logging to forensics, incident response and regulatory compliance.

In the beginning, you will learn what to do with various log types and provide brief configuration guidance for common information systems. Next, you will learn a phased approach to implementing a company-wide log management program, and go into specific log-related tasks that needs to be done on a daily, weekly, and monthly basis in regards to log review and monitoring.

Everyone is looking for a path through the PCI DSS and other regulatory compliance maze and that is what you will learn in the next section of the course. Logs are essential for resolving compliance challenges; this class will teach you what you need to concentrate on and how to make your log management compliance-friendly. And people who are already using log management for compliance will learn how to expand the benefits of you log management tools beyond compliance.

You will learn to leverage logs for critical tasks related to incident response, forensics, and operational monitoring. Logs provide one of the key information sources while responding to an incident and this class will teach you how to utilize various log types in the frenzy of an incident investigation.

Finally, the class author, Dr. Anton Chuvakin, probably has more experience in the application of logs to IT and IT security than anyone else in the industry. This means he and the other instructors chosen to teach this course have made a lot of mistakes along the way. You can save yourself a lot of pain and your organization a lot of money by learning about the common mistakes people make working with logs.”

P.S. Response to comments might be delayed, I am away from my computers.

Possibly related posts:

Wednesday, June 23, 2010

SLAML 2010 Log Analysis Workshop

This year, Workshop on the Analysis of System Logs (WASL) is reborn as SLAML. Please consider submitting a short paper (no need to do a full academic write-up!). The deadline is July 11.

Join us in Vancouver, BC, Canada, October 2–3, 2010, for the Workshop on Managing Systems via Log Analysis and Machine Learning Techniques. Modern large-scale systems are challenging to manage. Fortunately, as these systems generate massive amounts of performance and diagnostic data, there is an opportunity to make system administration and development simpler via automated techniques to extract actionable information from the data. SLAML '10 workshop addresses this problem in two thrusts: (i) the analysis of raw system data logs and (ii) the application of machine learning to systems problems. The large overlap in these topics should promote a rich interchange of ideas between the areas.

SLAML '10 combines the Workshop on the Analysis of System Logs (WASL) and the Workshop on Tackling Computer Systems Problems with Machine Learning Techniques (SysML)."

The part related to logs is:

Log Analysis: It is well known that raw system logs are an abundant source of information for the analysis and diagnosis of system problems and prediction of future system events. However, a lack of organization and semantic consistency between system data from various software and hardware vendors means that most of this information content is wasted. Current approaches to extracting information from the raw system data capture only a fraction of the information available and do not scale to the large systems common in business and supercomputing environments. It is thus a significant research challenge to determine how to better process and combine information from these data sources.”

The topics sought are:

“Topics include but are not limited to:

  • Reports on publicly available sources of sample system logs
  • Prediction of malfunction or misuse based on system data
  • Statistical analysis of system logs
  • Applications of Natural-Language Processing (NLP) to system data
  • Techniques for system log analysis, comparison, standardization, compression, anonymization, and visualization
  • Applications of log analysis to system administration problems
  • Use of machine learning techniques to address reliability, performance, power management, security, fault diagnosis, scheduling, or manageability issues
  • Challenges of scale in applying machine learning to large systems
  • Integration of machine learning into real-world systems and processes
  • Evaluating the quality of learned models, including assessing the confidence/reliability of models and comparisons between different methods”

Please submit to advance the state of log analysis research! Past workshop information is here (2008, 2009).
SLAML '10

P.S. This is posted by a scheduler; response to comments may be delayed since I might be away from computers.

Possibly related posts:

    Monday, June 21, 2010

    Ultimate Security Survey is ON!

    Securosis folks are starting off a new data security survey “focused on evaluating perceived effectiveness of various controls, as well as some other incident data.” In other words, they are starting The Holy Grail of Security Surveys: how/why what we do works or fails. It only takes about 10-20 minutes to complete – but can provide hugely useful data.

    Please participate!

    The survey is available at http://www.surveymonkey.com/s/datasec2010

    If asked for a code, enter "SecurosisAwesome"

    Enjoy!

    Wednesday, June 16, 2010

    How PCI Leads to DLP?

    By now, it is increasingly obvious that PCI DSS does not (and likely will not) mandate the use of Data Leak Prevention (DLP) technology now or in the near future. This applies to both discovery and monitoring/enforcement aspects of DLP. However, I am hearing that the percentage of DLP deployments driven by PCI DSS compliance is rising. What’s the story with that?
    While a certain percentage of such deployments  simply point “in the general direction of PCI” to get budget (huh…nothing wrong with that :-)), I’d like to comment on the fact that DLP often makes a decent compensating control for many PCI DSS requirements.
    PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance
    First, unless you read the PCI book already, read Branden’s chapter on the Art of Compensating Control (this paper [PDF] has some of the same coverage).
    So, here is where I have seen DLP boxes used as compensating controls (warning: evidence of QSA actually accepting it was not available in all cases, so use this advice at your own risk)

    • Stored data encryption (Requirement 3.4 “Render PAN, at minimum, unreadable anywhere it is stored”): DLP was used to compensate for the lack of STORED data encryption. The thinking was that if the data cannot leave the storage (…via the network), DLP was satisfying the same intent as encryption in the original requirement.  Would I agree that “it goes above and beyond” the original? Good question :-)
    • Access control (Requirement 7.1 “Limit access to system components and cardholder data to only those individuals whose job requires such access.”): DLP was used to reduce the chance of PANs falling into the wrong hands and thus satisfying the spirit of this requirement.
    • Monitoring access to data (Requirement 10.2 “Implement automated audit trails for all system components to reconstruct the following events:  […] All individual accesses to cardholder data”): while logging is a common choice here, DLP was used to make sure that all network access to cardholder data is recorded. The reason for choosing DLP over logging was due to the fact that the company didn’t know how to configure logging, but knew how to buy a DLP box :-)
    Others examples of auxiliary use of DLP for PCI DSS included verifying that Requirement 4.1 (“Use strong cryptography and
    security protocols such as SSL/TLS or IPSEC to safeguard sensitive cardholder data during transmission over open, public networks”) is indeed being followed. In this case, DLP served as a glorified PAN sniffer.
    On top of this, the discovery components of DLP tools are often used for scoping. See some fierce debate on this issue, referenced from here. To summarize, the use of DLP and standalone data discovery tools for PCI scoping is certainly not mandatory, but very helpful. On top of this, one can use a DLP system to make sure that scope does not explode when people pull card data from the payment environment to development, QA, etc, etc.
    Finally, I see the fact that PCI-motivated use of DLP tools is growing as something positive. To me it says that people are following the spirit of DSS and not simply its letter (of course, one can also say that they are reaching for a DLP box as an easy way out). Indeed, despite everything that was said above, deleting cardholder data is still a better way to make sure it does not get stolen or “lost”…
    (also, as a disclosure, I serve on an advisory board of a DLP company, nexTier Networks that has a product called Compliance Enforcer)
    Possibly related posts:

    Dr Anton Chuvakin