PCI SSC: Effective Daily Log Monitoring

PCI SSC: ‘Effective Daily Log Monitoring Supplement’ – They Missed Again

The SSC released their Information Supplement ‘Effective Daily Log Monitoring‘ in MAY, and I’m only just hearing about it now! Either I’m completely out of the loop (not being a QSA) or the SSC did a very poor job PR-ing it.

I think I understand which it is now that I’ve read it.

Anyway, despite the blatant oxymoron in the document’s title, and my own predisposition toward negative bias where the SSC is concerned, I was still hoping to be pleasantly surprised.

I wasn’t, but nor was I as horrified as I have been while reading output from other SIGs.

It’s actually a really good beginner’s guide to logging, but it’s completely unsupported by the DSS in its current form. And it’s not just me looking for faults, they have not put logging into a proper, or even accurate, context to the DSS requirements as written. With their knowledge of best practice, they basically made the rookie mistake of assuming requirements mean more than they do.

To be clear; If it’s not specifically spelled out in the standard, it is not mandatory. Period / full stop. Even if it’s the right thing to do.

For example: There is no requirement for any automated alerting. Not from firewalls, not from A/V, not from IDS, not from FIM, and not from ‘system components’ like servers and applications. So the statement; “The PCI DSS recognizes the importance of proactive monitoring of security logs in the detection of attacks on information assets and the protection of those assets from compromise.” is inaccurate. The SSC might recognise the importance of pro-active monitoring, the SIG’s participants clearly do, but the DSS only recognises the need for what amounts to forensic evidence. Nothing more.

The DSS uses the word ‘alert’ in only 6 relevant Requirements:

  • 6.6  For public-facing web applications, ensure that either one of the following methods is in place as follows:

• Examine the system configuration settings and interview responsible personnel to verify that an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) is in place as follows:

– Is configured to either block web-based attacks, or generate an alert that is immediately investigated.” – [Alerts are non-mandatory, and can be manually generated.]

  • 10.5.5  Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).” – [No time-period defined, so you have to assume weekly like 11.5, or at most daily like 10.6. Alerts can be manualy generated.]
    o
  • 10.6 Review logs and security events for all system components to identify anomalies or suspicious activity.

Note: Log harvesting, parsing, and alerting tools may be used to meet this Requirement.” – [Non-mandatory]

  • 11.1.d  If automated monitoring is utilized (for example, wireless IDS/IPS, NAC, etc.), verify the configuration will generate alerts to notify personnel.” – [Non-mandatory, and/or no time-period defined.]
    o
  • 11.4  Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.” – [Alert how? Automatically or during a daily review?]
    o
  • 11.5  Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.” – [Weekly notification, so clearly does not require automation.]

So if there’s no requirement for automatically generated alerts, and daily is the maximum defined review timeframe, how can they possibly insist on 24/7 availability related to Incident Response (DSS Req. 12.10.3)? Who is going to choose 2AM for their daily review?

Even the SIG makes the statement; “Without automated alerting mechanisms, it is almost impossible to identify and alert about such events in near real-time.“. In other words, in time to actually do something about it before it gets out of hand.

But I thought this was about effective DAILY log monitoring?

So All In All…

The thing that still confuses me most, is that the DSS is full of mandatory technologies, but a manual and daily review of logs is still OK?! Not one technology in the DSS is required to be utilised properly, and some have significantly less benefit than a Security Incident & Event Management (SIEM) or an equivalent managed service:

  • why require firewalls and routers then don’t mandate review of the traffic logs?
  • why require an asset database, but not an asset management system on which every other security processes can rely?
  • anti-malware is based on signatures so is all but useless
  • intrusion detection is pointless unless the entire infrastructure is baselined to a known-good
  • …and so on.

So of ALL requirements, how can centralised logging and automated alerts not be mandatory?

This post in already too long, and I’ve barely begun to scratch to surface of why logging and monitoring is so important.

There’s no escaping that the document name; ‘Effective Daily Log Monitoring‘ is misleading, it should be called the ‘We Cannot Tell You to Buy a SIEM, But Good Luck Getting Compliant Without One‘. Basically the SSC has all but admitted that the logging and monitoring requirements are completely inadequate, but can think of no way to change them in the DSS. Not without pissing off a lot of people anyway.

Finally, it IS  a good document, worth a read, and kudos to the authors. Unfortunately it’s guidance is meaningless to those without the means to perform anything other than manual daily reviews.

Bonus Material

If you’re interested, I have provided some additional thoughts in my own Logging Supplement document. There are 3 sections:

  1. Breakdown of Existing DSS Logging & Alerting (Non-Server) – There are 5 DSS requirements outside of the established logging and alerting requirements, and are ambiguous at best. They are also not covered appropriately in the SSC’s Supplement.
    o
  2. Missing from the DSS – The SSC’s Supplement did not cover daily review appropriately, nor did then then go far enough to cover appropriate automation. This section covers a few of the major benefits of logging and monitoring properly.
    o
  3. Automating the Daily Review – There are only three processes required to automate the daily review, but it cannot be done without centralised logging and scripting skills, a managed service, or a SIEM.

[If you liked this article, please share! Want more like it, subscribe!]

What is a Security Program?

It occurred to me that after 15 years of consulting, 10 years of public speaking, 3 years of blogging, and saying things like; “All regulatory compliance falls out the back-end of a security program done well.” and; “If you fail to develop an appropriate security program, it’s the CEO’s fault and no-one else’s.” that I have never actually defined what I consider to be a good security program.

In my defence, a good (i.e. appropriate) security program is as unique as the organisation trying to implement one. However, like any other discipline, there are basics that ALL security programs must have to be successful.

All of the best security experts on the planet pretty much agree on these basics. But just try looking for something you can apply to your business and you’ll soon be as confused as I am when trying to read anything written by a lawyer. Regulatory compliance, greedy product vendors, incompetent consultants and a whole host of other factors conspire to take security out of the hands of those who need it most.

Nothing I am about to write has not be said by me many times over, or by a thousand others much smarter than me, but for some reason it never seems to stick. As much as I hate the concept of rebrand-it-to-sell (e.g. a ‘service on the Internet’ is now called The Cloud), I can see the attraction. If we could make security ‘sexy and new’, perhaps we’d have an easier time bringing back the basics. 99% of security lives and breathes in the basics.

For example, everyone knows that there is no security program without senior leadership support (i.e. CEO). This is free, takes a fraction of a percent of the CEO’s time per calendar year, and has benefits well beyond anything you can imagine. But try getting it.

Anyway, on with the program detail, but first; If you don’t believe that a security program is a balance of People, Process, and Technology, stop reading, this will all be lost on you.

8 Steps to an Appropriate Security Program

o

  1. Senior Management Support – Been over this a million times. If you don’t have it, stop here, you’re wasting your time. Can you have some security without it? Yes, but guess who will be blamed when things go wrong.
    o
  2. Governance Committee – Senior stakeholders who will run the program with the full and visible support from senior leadership. Governance runs everything from risk assessments to change control, and without this centralised function your security program will collapse like a flan in a cupboard.
    o
  3. Policies & Procedures – Again, if you don’t know by now how important this one is, don’t bother reading the rest, you’ll never understand.
    o
  4. Risk Management – The primary function of the risk management is to ensure that all security controls meet the organisation’s risk appetite. Risk Assessment, Business Impact Analysis, Risk Treatment, and the Risk Register all sit here.
    o
  5. Appropriate Security Controls – No, I do NOT mean technology! Technology supports security, it does not define it. Your controls will be a direct result of the risks determined by Governance, and the requirements as defined in your policies (requirement for hardening guides for example). Technology purchases are the last resort.
    o
  6. Vulnerability Management / Change Control – I don’t lump these together very often, but from a program perspective, they have similar results. i.e Don’t make things easy for the attacker by a) ignoring the evolving threat landscape, and b) introducing potential vulnerabilities without due diligence respectively.
    o
  7. Testing Program – Test everything, then when you’re done, go back and test it again. Repeat. You simply have no idea whether or not your security program is working until you test it. Test results feed back into everything done before it in order to make the necessary adjustments.
    o
  8. Security Awareness & Training – Again, if this makes no sense, you’re reading the wrong blog. None of the above works unless EVERYONE knows what part they play.

That’s it. Finished. there is nothing more to do for any organisation to develop an appropriate security program. Nothing here is complicated, perhaps that’s why people ignore it, it’s just not dramatic enough.

However, making this process simple can be extremely difficult, as is getting the program in place, and these difficulties should not be underestimated. It’s the difficulty, not the complexity that ruins most security programs, especially when you don’t have the support you need.

FWIW, done well, a security program based on the above will not only make you more secure than most of your competition, but give you demonstrable compliance with every regulation out there. How’s that for an ROI?

[If you liked this article, please share! Want more like it, subscribe!]

Gartner’s Top 10 for InfoSec in 2016: 10 More Useless Acronyms?

On June 15th, Gartner released it’s Top 10 Technologies for Information Security in 2016. As a security ‘professional’ with over 15 years front-line experience, it has taken me this long to find out what half of these things are even trying to achieve. My initial impression was that this was just an attempt to corner the market on acronyms.

Now that I’ve had a little more time to look at them, it’s not just about acronyms, it’s about selling things. Things the vast majority of businesses don’t need. Things that if you DID introduce them into your current environment it would be like building a castle on a swamp (hope you got the Monty Python reference);

Utterly useless, expensive, and completely missing the point.

The breakdown:

  1. Cloud Access Security Brokers (CASBs), provide a “…critical control point for the secure and compliant use of cloud services across multiple cloud providers.” – In the real world this is called performing proper due diligence, before you outsource to a cloud provider. The right reporting should be built into the SLAs. Good God, even the PCI DSS makes this a requirement!
    o
  2. Endpoint Detection and Response (EDR), “EDR tools typically record numerous endpoint and network events, and store this information either locally on the endpoint or in a centralized database.” then compare the output to “known indicators of compromise (IOC)“. [Ed. note the 2-for-1 on the acronym front] – Why the Hell would you wait for a ‘known indicator of compromise’ instead of trying to fix the problem pro-actively first?!  Hardening guides, vulnerability management, system baselining, FIM et al are all designed to produce baselines of known-good configs thereby minimising exposure. This is nothing more than a rebranding of basic security tenet in order to sell a technology.
    o
  3. Non-Signature Approaches for Endpoint Prevention, uses “machine learning-based malware prevention using mathematical models as an alternative to signatures for malware identification and blocking.” – Seriously (see 2. above)? Once you have your system at a known-good config, stop anything NOT that. Are you seriously going to spend God-knows how much on a new technology instead of doing what you SHOULD have doing all along …for free(ish)?
    o
  4. User and Entity Behavioral Analytics (EUBA), “…provides user-centric analytics around user behavior, but also around other entities such as endpoints, networks and applications.” – This one just pisses me off, and I can only assume Gartner were paid a ton of money by EUBA vendors to add this to the list. This is the THIRD nod to baselining and I’m only at number 4 on the list.
    o
  5. Microsegmentation and Flow Visibility, which is basically more granular segmentation (think system-to-system instead of the usual network-to-network). – So let’s see; most organisations have horrible segmentation at the network level, so to combat this, buy a technology that puts the ‘firewalls’ on each endpoint and maps your traffic flows at that level. I have an idea, why don’t you just do segmentation properly with the infrastructure you have and THEN decide if you need more. I seriously doubt you will unless you’re an IaaS/PaaS provider.
    o
  6. Security Testing for DevOps (DevSecOps) – In other words; building security and security testing into every step of the development process. This is new? I have to assume this was just padding to avoid a Top 9 scenario.
    o
  7. Intelligence-Driven Security Operations Center Orchestration Solutions, “an intelligence-driven SOC [ISOC] also needs to move beyond traditional defenses, with an adaptive architecture and context-aware components.” – So what you’re saying is; Let me know if something happens that’s not normal? Errr, isn’t that reporting events outside of a KNOWN-GOOD BASELINE!?!
    o
  8. Remote Browser solutions “…remotely present the browser session from a “browser server” (typically Linux based) running on-premises or delivered as a cloud-based service.” – This one kinda makes sense, but haven’t we had jump-servers for decades that could do something very similar?
    o
  9. Deception “technologies are defined by the use of deceits and/or tricks designed to thwart, or throw off, an attacker’s cognitive processes, disrupt an attacker’s automation tools, delay an attacker’s activities or disrupt breach progression.” – Anyone who uses this technology deserves to be hacked. This is perhaps the stupidest concept I have ever seen and I cannot believe it’s on anyone’s list. Gartner should actually be ashamed of themselves.
    o
  10. Pervasive Trust Services, “As enterprise security departments are asked to extend their protection capabilities to operational technology and the Internet of Things, new security models must emerge to provision and manage trust at scale.” – Finally we agree on something; centralised management of end-points based on known-good configs.

As far as I am concerned, 99.9% of organisations can effectively ignore this Top 10 list. You will NEVER find a technology that fixes stupid. Just do security properly and you’ll achieve what every organisation is looking for; appropriate, value-for-money, security.

It’s a shame Gartner can’t monitise a ‘Top 10 Information Security Back to Basics’, that would actually be worth a read.

 

An Agile Security Program? I Don’t Think So.

In my vast experience of the Agile Methodology (just over a month now), I have managed to go from a proponent (as in Running PCI as an Agile Project?) to someone who is rather more circumspect when the objective in question falls outside the realm of a short-term project. An easily defined short-term project at that.

In other words, NOT a soup-to-nuts security program.

The overused adage; “If all you have is a hammer, everything looks like a nail.” is particularly relevant here, as Agile proponents have actually gone looking for nails to the point where some security ‘professionals’ are designing their entire program around this single tool! Being generous, this shows a spectacular naiveté,  at worst, it shows a complete ignorance of what constitutes a sustainable and effective security program.

And to be clear; Agile is a tool, nothing more. It is not a philosophy, it’s not even a framework, it is used for very specific requirements at very specific times for an easily quantifiable result; like a new user interface, a segmentation project, or even the installation of a centralised logging technology. Where it make absolutely NO sense is the exact place a good security program starts; with the culture.

The implementation of a good security program has always been, and will always be, more art than science, and completely dependent on the prevailing culture, a culture defined by the CEO’s attitude towards it. In other words, trying to implement a security program AND instill a culture at the same time with nothing more than a single tool, is no different from trying to build an entire house with just a hammer. It simply does not work that way.

Also, those focusing on Agile tend to come from a highly technical background and therefore focus on technology over process, which just compounds the problem to the point where any short-term gains will be built on nothing but air (like my sandcastle ‘metaphor’). Technology is critical for the automation of KNOWN-good processes, it can never be the solution in and of itself.

In one of my first blogs I posited that there are only Four Foundation of Security:

  1. Management Buy-In / Culture
  2. Policies & Procedures
  3. Governance
  4. Education & Training

…I would now actually add a fifth; Vision (or perhaps just include it in the first one), as it’s the CEO’s vision for the organisation that will drive the development of an appropriate security program.

Assuming you agree with the Foundations, perhaps you can now see how using Agile for any one of them is utterly meaningless. Implementing two week sprints and daily stand-ups to ask whether or not the CEO has signed-off on the security policy framework, or if all relevant staff have taken their annual awareness training, makes no sense whatsoever.

In the development of a security program, a competent security practitioner at the CSO / CISO level would usually follow these steps (gross oversimplification):

  1. Get the CEO to agree to take an active role in the program’s implementation / socialisation. Get this in writing.
  2. Define the governance framework to get all relevant senior stakeholders to the table. Have the CEO ratify it.
  3. Draft Information Security Policy Framework for the policy committee’s review and approval. Have the CEO sign it.
  4. Distribute the relevant policies to the right people as part of the socialisation and initial training exercise. Have the CEO visibly endorse it.
  5. Implement an ongoing awareness program to solidify the culture changes. Have the CEO evangelise it.

If you can’t even get the first step in place, you needn’t bother with the rest, as no matter what you do your security program will collapse under the weight of indifference.

No tool is going to fix this, certainly not Agile.

Buzzwords Are Killing Real Security!

If you’re a security professional and there’s a new phrase or product going around with which you are unfamiliar, there’s a better than even chance you won’t need that thing. Ever.

The reasons are myriad, but the major offenders are:

  1. It’s something that product vendors invented to scare you into thinking you’ve missed something; [e.g. Advanced Persistent Threats]
    o
  2. It’s something Gartner was paid to promote into a magic quadrant of some sort, [e.g. most of Gartner’s output]
    o
  3. It sells column inches, or;
    o
  4. It’s something you already have but now it has a sexier name. [e.g. Logging and Monitoring is now Security Incident and Event Management (SIEM)]

For me, this pet peeve started with ‘The Cloud’. Suddenly everything had to be “In The Cloud”, that adoption of Cloud-based services was the only way to stay up with your competition …blah blah blah. Basically The Cloud was the only way you were going to stay in business in the digital age.

“But wait David!” I hear you gasp; “Isn’t The Cloud just an application on the Internet? Haven’t we had this capability for, I don’t know, DECADES!?!” Why yes Dear Reader, we HAVE had this capability for decades, but clearly you didn’t know you needed it until it had a fancy name and had vendors shoving the concept down your throat!

I know of organisations who quite literally renamed their ‘Managed Security Services’ to ‘Cloud Security Services’ without changing a SINGLE piece of infrastructure or a single process. And yes, this hid all manner of sins, but for some reason the new name stopped clients asking difficult questions like; “Can you tell me how it works?”

By sheer coincidence, I gave a webinar last week titled “Ignore Future Attacks, Fix Your Broken Security Program First”, it could just as easily be called “Ignore Buzzwords, Fix Your Broken Security Program First” and the content would be almost identical. We need to stop focusing on the new when we usually don’t even know what assets we’re trying to protect, who has access to what, or what any given system should look like from a normalised perspective.

Business needs information in context in order to compete, and the data that makes up that information is stored somewhere on a physical system. I don’t care if it’s virtualised, containerised or whatever-ised, it’s still a piece of hardware running an operating system sitting in a room somewhere (yes, I know it can be distributed). Nevertheless, there is NOTHING you need outside of an established good security practice to protect this data from what’s out there now, and what will be out there in the future. REGARDLESS of its name!

Segmentation, configuration standards, access control, logging and monitoring and a host of other old fashioned and boring names all boil down to one thing; baseline. What should a system look like all day every day, and how do I report anything different. No innovation in security capability (i.e buzzword) will be of any use whatsoever if you don’t have the basics right, because you’ll have no idea what you have, let alone how it should normally behave.

Ignore the hype, ignore the press, ignore Gartner and their ilk, focus on the stuff that you’ve likely relegated to a ‘previous generation’s problems’. They are still your problems too.