PCI – Going Beyond the Standard: Part 17, Vulnerability Scanning & Penetration Testing

Far too often, security is seen as a project, especially if PCI compliance is the goal. The requirements for vulnerability scanning and penetration testing are therefore seen as just another tick-in-a-box and their significant benefits lost.

External vulnerability scanning is the only requirement which must be outsourced and run by an approved scanning vendor (ASV, list here), the other requirements; internal vulnerability scanning, external penetration testing and internal penetration testing can by run by internal resources IF, and ONLY if, you can adequately demonstrate the requisite skill-sets in-house.

Of course, in order to save money, it is very tempting to skate by on the bare minimum, and unfortunately some security vendors (including QSAs) will allow you to do just that. Which is a shame, almost to the point of being irresponsible, as no other requirements give you a truer indication of your actual security posture than these.

Think of it this way; the bad guys use the EXACT same techniques to break into your systems that the good guys use to tell you what’s wrong. The ONLY differences between a hacker and an ethical hacker are intent and moral code, the skill-sets and mind-sets are the same.

Between vulnerability scanning and penetration testing, you have roughly 50% of your vulnerability management program sown up. Patch management management, risk management etc. make up the rest. However, the trick that’s almost always done poorly – if at all – is the integration of vulnerability management with asset management and change control. Any change to your environment should have appropriate vulnerability management processes around them, from a quick directed scan to a full blown credentialed penetration test, and all should be in-line with agreed configuration standards (as defined against each asset).

Going above and beyond PCI in scanning and pen. testing is relatively simple, but it’s not cheap in terms of resource cost. It also demands a maturity of process and a significant shift in culture to accept the ‘overhead’, but it’s more than worth it:

1. External Vulnerability Scanning – No choice but to use an ASV, but you should choose a vendor that provides 2 things at either no, or little, extra cost; Monthly scans (PCI requires quarterly), and unlimited directed scans (against single IPs, or subnets). Performed correctly, monthly scans and directed scans initiated by change control processes go significantly above and beyond. Note: For PCI do NOT open your external firewall/routing devices to your ASV’s IP addresses. Why would you decrease your security posture to test your security posture? Just run one scan for PCI, and THEN open your firewalls so that scanners can do a more thorough job. Keep these profiles separate, one for PCI only, one for your entire business.

2. Internal Vulnerability Scanning – You can do this yourself, and I’ve lost count of the number of clients running basic installations of Nessus, but unless you have significant expertise in how to configure it AND understand the results, don’t do it. For a start, any good QSA will fail you for lack of expertise, but do you really have the time to keep it up to date? Again, running internal scans monthly and as directed by change control goes above and beyond. Having two scan profiles is also a nice feature, but if the scan engine is capable of doing more than just rattle the windows (in the ubiquitous house analogy) and can actually perform a deeper scan / reconnaissance, then you have knocked this one out the park. PCI compliance is never security, do internal scanning as far above PCI minimums as you can afford.

3. External Penetration Testing – PCI requires that you attempt to break in (without breaking) via your Internet-facing presence, but poor guidance on what the test should consist of, combined with an enormous price-compression of pen. testing services means that this effort is usually more automated than I would consider appropriate. A pen. test is supposed to be a person with the necessary skills trying for days on end to discover ways into your systems. This is rarely the case now, but is EXACTLY what your should be doing. The Internet is where most breaches originate (used to be internal), so having a VERY robust security posture from the-outside-in is of paramount importance. Do NOT skimp on this one.

PCI calls for annual pen. tests, and to go above and beyond you need to perform these more frequently. This should not be an enormous cost, and most pen. test vendors can provide an infinitely scalable service based on scope and call-off days.

4. Internal Penetration Testing – Same premise as the external pen. test, but this time from the inside. PCI requires that this test simulate an attacker ‘plugging in’ where the admins sit and seeing what they can do from scratch. Above and beyond is therefore very simple; give the pen. tester FULL access to the environment, as well as credentials to go even further where appropriate. Like scanning, you have one test for PCI, then another test for your business.

There will be times when a simple vuln. scan of a system that has undergone change is not sufficient, so having a directed pen. test process available for critical business changes is very important.

None of the above processes should be stand-alone concepts, and should be very tightly integrated with risk assessment, change control and asset management processes to be truly effective. Vulnerability Management represents the end to each cycle of your security program (Plan > Do > Check > Act > Repeat), and ensures that your security posture always remain in-line with your business goals.

It bears repeating, do NOT skimp on this requirement, you will pay far more when you have to clean up the mess after a breach.

The Evolution of Privacy, We Aren’t There Yet

For those looking for a considered, well researched, and unbiased post on the ACTUAL evolution of privacy, you will be disappointed. This is an opinion piece based on my own theory of WHY people want privacy as much as they do, and whether or not they truly understand its implications. Well, my interpretation of those implications anyway.

I do not believe human beings to be either civilised, or that intelligent. We’re heading in that direction, but need to get out of our own way first. From a continued reliance on religious dogma, to a universally accepted misunderstanding that we are more than just another mammal, to the overwhelming prevalence of ignorance, we are no closer to any form of enlightenment than were the people ~1,000 years ago in what we call The Dark Ages. 1,000 years from NOW will be seen as The Dark Ages – Part II, and you just have to read the news each day for a hundred examples of why.

So what are the benefits of privacy? Why did we evolve the concept of privacy to the point now where it’s a Human Right ratified by the UN as Article 12; “No one shall be subjected to arbitrary interference with his privacy, family, home or correspondence, nor to attacks upon his honour and reputation. Everyone has the right to the protection of the law against such interference or attacks.”

As far as I’m concerned, the only reason for this is that NOT having privacy puts you or yours at some kind of risk. Regardless of our sentience, we ARE just animals, and subject to the exact same primal urges as every other mammal. The need for food, water, sex etc. are at the base of Mazlow’s Hierarchy of Needs, but security of body, family and property is only just above them.

If we had truly evolved as a society to the point where these basic needs are provided, there would be little need for privacy. If we didn’t go through life knowing that our ‘secrets’ could be the cause of ridicule, alienation, resource loss, or even physical harm, then the requirement to keep-it-all-to-ourselves would be unnecessary. But we are still in the position where the bad outweighs the good, and the ignorance perpetuated through religion, sex / sexual orientation / colour biases, and political doctrines ensures that these fears are far from unfounded.

The challenge we face is that privacy is one of the biggest reasons we HAVE a perpetuation of ignorance. Human nature does not fall on the side of trust, what we don’t know scares us. At its mildest form, this mistrust keeps us from having as many friends as we’d like, at its extreme, we end up destroying what don’t understand.

All human interaction is based on one thing; trust, and no-one trusts words, only actions. For example, if I was to open my life up to detailed scrutiny, then recorded the results of that scrutiny in a way that’s irrefutable, everyone who ever met me, for any reason, would know exactly with whom they were dealing. My values, level of integrity, likes, dislikes, aspirations, biases and so on would be my permanent and openly available CV/resume. Business partners, employers, potential friends, ANYONE would be able to make a fairly immediate decision as to whether they wanted to proceed. Even if they didn’t LIKE what they see, which is entirely possible, they’d still know enough about me not to be scared of the unknown.

If nothing else, it would save a great deal of time never talking to someone with whom we fundamentally disagree, or whose personality is one we would find offensive.

Finally, if we all have the right to privacy, then NO-ONE has the right to complain about those with bad intentions using it to cause harm. Until Human Rights are a currency – which they should be – our evolution as a species will be stunted by fear, uncertainty and ignorance.

Security Vendors Offering Guarantees Is Totally Irresponsible

Who has seen this; Zero Malware Guarantee, or something like it?

More to the point; who saw this and thought what a load of boll$£@?

Anyone who knows even the most basic aspects of information security knows that the ONLY guarantee is that nothing is safe. Ever. And to throw out a word like guarantee is nothing except the most despicable attempt to drive business in a field where the experts are SUPPOSED to be trusted.

What IS the guarantee?; “…to detect and stop 100% of all malware propagated over the web which is capable of being scanned by the [blah blah] Service.” Did you notice the word CAPABLE? Who wrote this, lawyers?

What’s worse, here’s what you get if they FAIL to detect and stop 100% of the malware; “…you will receive a one month extension of the term of your [blah blah] Service subscription”

Seriously? It didn’t work, but you get one more month for free?

Doctor to dying patient: “The drugs we gave you aren’t working, but here, have some more on the house.”

Surely if the product is that good, this vendor and vendors LIKE them (there are many) should WARRANTEE their products. “If we screw up we’ll pay for the fix AND give you your money back.” Now THAT’S something worth considering.

You can guess how often that will happen.

The reason this is so offensive to me is that security is already seen as something to spend money on only because you have to (like insurance), and this crass commercialisation of yet another security PRODUCT just makes everyone in the security field look like ambulance chasers.

Eradication of malware (as in the above example) STARTS with policy and procedures, continues on with parallel efforts in security awareness training and control definition, and is maintained by a security program done well. Just like every other aspect of security. So the only reason security companies keep coming up with these snake oil ads is because people keep buying stuff from them.

I can empathise with organisations struggling to understand security and buying what they think is the right thing for their business, but I cannot even begin to condone any organisation selling something TO those organisations when the seller damned well DOES know better.

You never need guarantees in security, you only need appropriate security, and you can start by avoiding any organisation that begins with making false promises.

PCI – Going Beyond the Standard: Part 16, Logging & Monitoring

From everything I have seen in my many years performing PCI assessments, logging is not only one of the least understood of the requirements, it is the most under-utilised, and the one that gives/gave my clients the most pain.

Logging is the most important detective security control you have, bar none, and done correctly, logging is the foundation of your incident response program. Notice I didn’t say ‘disaster recovery’ as well, because if your incident response was where it should be you should not HAVE to recover from a disaster.

The confusion stems mostly from a lack of understanding of logging mechanisms themselves, even for Windows (for which PCI was clearly written). For example, do you think that Windows logs to the PCI requirements out of the box? I did too, but have been assured that it does not. Do you know HOW to get it to log appropriately? No, me either.

I have been further assured this if you WERE to turn logging on to cover the 10.2.X requirements, the logging would be so verbose as to render the device that’s doing the logging useless. Is that really the INTENT of logging? Of course not.

Also, can syslog EVER record the events required in 10.2.x, or even the event content as required in 10.3.x? Once again, I have been told no, but I am no expert.

Yes, you SHOULD have people who DO know this stuff, but how many organisations out there can truly afford that kind of deep expertise in-house? Yes you can outsource, but where is the guidance on EXACTLY how to configure operating systems to log to the PCI requirements? It probably exists, but in 8 years of doing PCI I have not found it, and I’ve even asked ‘experts’ in the field; Security Incident and Event Monitoring (SIEM) vendors. On that note, I have yet to see a SIEM vendor also be an expert in PCI, which to me is an absolute joke if that’s why they are selling it to their clients.

We have free hardening guides for Windows (CIS Security Benchmarks for example), but where is the guide that breaks down the Windows operating system into a mapping between the registry settings for logging and the PCI DSS? Or *nix flavours, or Cisco, or AS400, or Power Series? If you have them, please share?!

So let’s, for the sake of argument, assume that you cannot reasonably log to the letter of PCI, or more to the point, you do not WANT to for usability issues. Are you non-compliant? Let me answer that with another question; What’s more important, configuring your logging to record events for a forensics investigation, or configure your logging to help prevent a breach in the first place?

If you chose the second one, you are correct, and if you also choose to maximise your logging mechanisms, you will not only be PCI compliant to its intent, you will also be doing security properly.

First, logging is not about crunching masses of data through a correlation engine, its about the RIGHT data put into a base-lined context. There is no such thing as log event correlation without a deep understanding of what the end systems SHOULD look like, AND what your normal business processes are from start to finish. In other words, tell any vendor trying to sell you compliance though their SIEM, exactly where to put it.

While we’re on the subject of SIEMs, how many of them do you think can accept Windows logs natively, or have to convert the logs to syslog via an agent (e.g. Snare)? Very few. What’s the point of buying a log mechanism that cannot even read WINDOWS events without butchering them DOWN to syslog?! You MUST ask the right questions before buying ANYTHING, especially a SIEM.

OK, so how DO you go above and beyond? Simple, in one way;

Do NOT perform your log reviews daily (10.6), because that’s just plain stupid, not to mention impossible to do adequately. Perform log reviews in real-time via some form of automation.

The automation you need is threefold;

  1. Events you should NEVER see: Each system admin, from OS, to network device to application SHOULD know which they events should never be seen under normal operating conditions. Look for these ‘strings’ and alert immediately.
  2. Events you should not see in a certain quantity and velocity (i.e. thresholds): I don’t care if I see an admin fail to log in once, I do care if s/he fails 10 times in 2 seconds (for example).
  3. Quantity of events over the course of time (i.e. trending): You have to save logs for 1 year (DSS 10.7), so why not put them to good use by trending events over time? Even if it’s just quantity of event (as opposed to quantity of type of event per device), the information you get can be extremely useful.

Perform all three of these things, and you have not only covered the ridiculous ‘daily reviews’ automatically, you now have input into your incident response mechanism that gives you real security.

Choosing the right centralised logging mechanism for your business is one of the most important decisions you can make, and it cannot be done ONLY for PCI. You must buy a system that can cover you enterprise-wide, and unless you have significant in-house expertise, you must build into the RFP the requirement for consulting support. Nothing stays the same, so your future state / needs will also need to be taken into account.

Do NOT penny-pinch here, but don’t buy anything that’s not appropriate. Your risk assessment process should tell you exactly what you need, and if you’ve not done one, start there.

The Past is Just a Story We Tell Ourselves

I’ve heard similar phrases to the blog title my whole life, most of which are part of some sickly sweet – and more than a little trite – life-confirming, motivational poster. The kind that usually have kids hugging, or a kitten, or kids hugging kittens.

For some reason, hearing it again during the movie “Her” made a much deeper impact, probably because the movie itself addresses human emotions in a way that is different to anything I’d ever seen before, but perfectly captures something that I have contemplated at many times in my life; emotions are not tied to reality.

It’s not a spoiler, but the main character falls in love with an operating system. Yes it helps that it’s the voice of Scarlet Johansson (the visual certainly does anyway), but nevertheless, she is an artificial intelligence that achieves a simulacrum of humanity, including emotions, and even attempts a more physical demonstration of her feelings.

The point of this blog is not the movie (which is absolutely stunning), it’s that we do something very similar every day. Not to the same extent clearly, but how many times do we invent intricate stories behind some perceived slight that makes the offending party out to be some kind of jerk?

“How DARE they drive slowly in the overtaking lane, they KNOW I’m behind them and are doing it on purpose!?”

“They didn’t return my call, obviously they don’t respect me.”

“The team did not invite me out to lunch, they are probably talking about me!”

On the other hand, how many times have we confronted the offending party/ies about this just to find that they have no idea what we are talking about, and either have a perfectly reasonable explanation for the assumed slight, or are genuinely sorry to have caused us pain unintentionally?

Yet the pain is still there, isn’t it? And we still judge them harshly, sometimes for a significant time after the event, don’t we?

And some of us never forgive.

It does not matter to us humans whether or not the cause of the emotion (love, fear, hate etc.) is real or not, the brain reacts the EXACT same way. From initial reaction to the stimulus, to the retention of the long term memory, real and unreal are identical. WE create the story of every aspect of our lives, and unfortunately we also tend to defend those stories even in the face of all evidence to the contrary. Some call aspects of this ‘faith’, I call it excuse to stop thinking, regardless of the subject.

Anyone who has fallen in love with you for whom they WANTED you to be is no less hurt than someone you intentionally fooled. The responsibility shifts, but the results are the same; they get hurt.

Add to this that most people will naturally assume the worst, not the best, and you have the recipe for a long line of stressful encounters. For example, when was the last time someone was late for a meeting and you assumed they had just won the lottery? Each of these negative stories we invent just reinforces the previous ones, and before long, we are looking at all situations and people through sh!t-coloured glasses.

People who tend towards the judgemental are constantly comparing others actions to their own, and as a result of those actions failing to meet the required standard, create negative stories about people they barely know. Combine judgment with an unforgiving nature and you have a person surrounded by enemies. All in their own minds.

I have no solution for this, I do it myself constantly, but being AWARE of my tendencies has allowed me to be far more flexible, and that can only be a good thing.

PCI – Going Beyond the Standard: Part 15, Physical Security / Back-Ups

The physical security requirements of the PCI DSS are by far the easiest to meet to the letter, but even these cause an inordinate amount of pain. This pain is rarely caused by the requirements themselves, but by the interpretation of them.

For example, if you were in-scope for the physical aspects, and I was to ask you if you HAD to have cameras to achieve PCI compliance, what would you say?

I you said something like “Not necessarily.”, “That depends.” or even a simple “No.”, you are correct. And if you don’t agree with that, just read the DSS;

“9.1.1 Use video cameras and/or access control mechanisms to monitor individual physical access to sensitive areas.

I’ve used the word ‘intent’ many times in my blogs about PCI, because the intent of a requirement is always more important than the words written. Unfortunately, a lot of my clients, or even their QSAs, don’t even read the words, let alone interpret the language into something the business side can understand.

The intent of the physical requirements is that you restrict access to only those who need it, and that you keep record of who was where, when. That’s it, and if THIS is too much, you have more problems than PCI.

Above and beyond is very simple, but there are too many options to go into here. Decide via your risk assessment process what is appropriate, get the relevant guidance if you don’t have it in-house and stick with that.

For back-ups, this is just as simple, and the requirements are written down for you. However, there are some gotchas that I will address here;

1. “9.6.1 Classify media so the sensitivity of the data can be determined.” does NOT mean that you have to LABEL the media AS sensitive, it just means that you have to have a way of distinguishing the media that may contain sensitive data so that you can protect it accordingly.

2. If you do have physical media that contains cardholder data, the decryption keys are not included, and the offsite facility has no means to GET access to the decrypt function, this media can be reasonably classified as out-of-scope for the same reasons P2PE is a de-scoping option for retail.

3.  Far more prevalent these days is some form of network access storage (NAS) where the data is ‘striped’ across many disks. From my perspective, because the theft of any one (or even several) disks does not constitute the theft of reconstitutable cardholder data, only the management station used to control the access to the data and NAS functions is relevant. Here all PCI controls relevant to a server would apply.

4. You must make sure you have a well defined Data Classification Policy or the data retention and destruction requirements have no context, and cannot be properly validated. You will probably end with a ton of data you don’t need and your overall risk will steadily increase over time.

5. Go back over all of your business processes that could have ever resulted in the retention of cardholder data and deal with the resulting media accordingly. This includes paper.

Finally, the new-to-v3.0 requirements for the protection of “devices that capture payment card data” (DSS Reqs. 9.9.X). Bottom line; if you don’t have this stuff in place already, I can’t help you, and you may want to consider alternate employment options.

Not much more to say here, but I don’t want to underplay this too much and make the mistake of the curse of knowledge.  knowing where your sensitive data is in ALL it’s forms is critical, and both your physical access to it, and the protection / destruction of it, are extremely important concepts.

Security Done Well, The Ultimate ROI

To accept anything I’m going to say in this post, we need to agree on the definition of ‘investment’. The OED has 3 definitions;

  1. The action or process of investing money for profit
  2. A thing that is worth buying because it may be profitable or useful in the future
  3. An act of devoting time, effort, or energy to a particular undertaking with the expectation of a worthwhile result

For the purposes of this blog, I’m taking the word ‘useful’ in definition 2, and the entirety of definition 3. I’m not that biased toward my chosen profession that I believe spending money on security will actually make you money, but I do believe that any effort to stay competitive in this day and age requires the current perception of security to be completely overhauled.

I have compared security to insurance, law, and chewing tinfoil; you only do it because you have to, it’s too complicated, and it’s very irritating, respectively.  It’s no wonder that it gets the short-shrift that it does, especially when one or all of these comparisons come from the CEO him/herself.

If you can also accept that not LOSING money is also a ROI, then we can begin.

I was recently told that unless we security experts can put security into terms the business side of an organisation can understand, we’re wasting our time. I’ve done that my whole career I thought, but I missed the trick of putting security into a financial CONTROL perspective, mostly because finance is not my background. So thank you Jeff Hall for that.

These are my Top 5 reasons that security provides an ROI well above that of almost all other individual departments, including sales.

  1. Competitive Advantage
    I have touched upon this in several blogs, but the basic premise is that in the information age, the majority of businesses are almost entirely based on the manipulation of some form of data. Data in context is information, information in context is knowledge, and knowledge applied correctly is wisdom, and so on. It follows therefore that the ages old concept of Confidentiality, Integrity, and Availability (C.I.A.) very much applies, so if your data is the foundation of all of your businesses services, why is it not treated accordingly?
  2. Business Transformation
    Similar, but different enough from Competitive Advantage to warrant its own section. Again, seeing as data is central to all things, the ability of an organisation to order, compile and retrieve their accurate data faster gives them the ability to adjust their processes in the face of customer needs, or competitive threat. If you don’t know what you have, or in detail how you do what you do WITH what you have, you cannot make change fast enough. Competitive advantages in the Information Age last weeks / months, you simply don’t have years to  catch up.
  3. Financial Control
    All finance these days is just data in context, and while security will never be able to provide that context, access TO, and the integrity OF the data can provide a much welcome check and balance for the control of an organisation’s financial data assets. Regulations like SoX have security as part of their requirements, but it goes no-where near far enough to provide much benefit. A security program done well would cover this and a whole lot more.
  4. Avoidance of Fines / Loss of Reputation
    Globally, more and more regulations are in the works that can have significant negative monetary implications. PCI is probably the best known, but the Information Commissioners Office (ICO) here in the UK can fine up to £500K per event for the loss of personal data. The EU Data Protection Directive (if it ever gets off the ground) can impose fine of up to 2% of GLOBAL revenue for a similar loss. These fines are monetary, but the loss of reputation can potentially be far worse.
  5. Cheaper IT Infrastructure and Maintenance
    This may seem strange, even counterintuitive, but you only get real security when all the processes are simple, and you can only achieve simple if everything you have is a known-good, or baseline. These baselines are hard to achieve, and can be expensive in the short-term, but the long term costs are significantly lower than trying to either constantly work with too much (technology, data, people etc.), or fix what’s broken because you couldn’t detect a problem in time to prevent it from becoming a disaster.

Security is simple, and done well provides benefits way beyond what most business people can possibly envision, but ignorance of this has always been, and will always be, the CEO’s fault;

“Let’s be very clear; The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities.  If the organisation fails to achieve [enter goal here], it’s the CEOs fault, and no-one else’s.”

Just ask Target’s outgoing CEO if he wished he had paid more attention to security.

PCI – Going Beyond the Standard: Part 14, Access Control

There is no going above and beyond the PCI standard in this one, as every definition of Role Based Access Control (RBAC) is what is required. i.e. You must reduce the access to any system / location / data to only that required, based on the job responsibilities of the individual accessing it. Period / full stop.

So why doesn’t the PCI DSS just come out and SAY it must be RBAC? Because there are other ways of doing this that fall outside of the pure definition (a combination of Mandatory Access Control (MAC) and Discretionary Access Control (DAC) for example), and the SSC can never insist on something that may not be appropriate for all sizes of merchant and service provider alike. Just look at logging; you don’t HAVE to have a centralised logging mechanism (e.g. SIEM), but try performing the 10.5.X and 10.6 requirements without it.

The fact that there are not separate PCI standards for merchants and service providers, as well as separate standards for types of business (retail, e-comm, micro-merchant etc.) is why there is so much confusion, and why almost every self-assessment is BS. Yes, there are Self Assessment Questionnaires (SAQs), but these are reporting mechanisms only. Regardless of which SAQ you are asked to complete, you are still responsible for compliance to all DSS requirements. Combining all requirements, regardless of business, into one standard is like trying to describe an average human being. It’s the nuances that matter.

But I digress.

In practice, access control is almost universally performed badly, as it is seen as inefficient in terms of work product, too complicated to set-up, too labour intensive to maintain, or a combination of those three. Then there are the organisations who consider themselves too small to bother, or the ones for whom this is an alien concept. Yes, there are still some of those out there.

While you cannot go above and beyond this ultimate in security baselining, you can perform the function in a way that ensures that it automates much of the enforcement of RBAC, as well as produces the management information required to measure the appropriateness of the implementation.

Step 1 – Paperwork: Un-surprisingly enough, good access control starts with a Policy, is included in all relevant procedures, and is appropriately defined in relevant standards. Other than the Access Control policy itself, the most important paperwork foundation is the Data Classification Policy. RBAC should be tied to the level of the data involved, and without an understanding of data classification, this determination cannot be made. For example; a DBA who manages all financial or intellectual property, should have far more restricted access, and exponentially more applied oversight, than should the guy in charge of your public data.

Note: Steps 2 and 3 should be performed in parallel, and combined into an overarching management process that is managed though an Asset Management System (AMS);

Step 2 – Human Resources (or equiv.): Whatever unit in your organisation manages what has – until fairly recently anyway – been called HR, should have a complete understanding of the on-boarding procedures for every role within the organisation. While every employee begins with the exact same core procedures (paperwork, corporate training, assign email / domain access etc.), well defined roles will then continue along functional on-boarding road-maps. Depending on the organisation, there can be few or many of these, but either way, this needs to be generic enough to manage, but detailed enough to reduce the burden of requesting the remaining individual privileges required. For example; a Windows admin may be granted access to all Windows desktops on joining, but will have to earn the right to access critical Windows servers, and make a separate request through channels.

Step 3 – Asset Management: Asset Management is a critical aspect of access control. Well, asset management done correctly, gives you the ability to effect proper change control, because nowhere else in your organisation does the mapping of data / application / system to data classification occur to such an extent. Seeing as access control is enormously impacted by data classification, the only place where system / data / process ownership is fully defined is the asset register / database.

Step 4 – Enforcement: For every asset type, you need an enforcement mechanism around it. This will ideally be centralised (Active Directory, TACACS, RADIUS etc.), but sometimes local access lists are appropriate. 2 factor authentication (2FA) and/or separation of duties may be appropriate for critical systems, but not for guest wireless access, but whatever is chosen must be [yet again] appropriate in terms of sustainability, and security level.

Step 5 – Ongoing Management & Review: Over 90% of all processes fail because the necessary mechanisms were not put in place to sustain them. From management buy-in, to process definition, to initial implementation, to employee training, to culture shift, unless the process is part of an ongoing and enforceable life cycle it will die on the vine.

There are as many ways of effecting appropriate access control as there are organisations requiring it, so the above is as specific as I can get. How you implement this is your organisation WILL require a significant expertise, so if you don’t have that in-house, go find it.

If you don’t know what questions to ask, ask someone who does.

Be Careful What You Get Good At

Preposition aside, this is one of those phrases that invoked a flood of thoughts in a direction VERY different from the original context. I heard this one on True Detective, the phenomenal HBO series, when Matthew McConaughey used the phrase to explain his own rather dark abilities. Wayyyyyyy different from anything I could, or would, want to write about, but inspiration is rarely linear.

Also not a new phrase obviously (it’s based on Gabrielle Hamilton’s quote), but one I was hearing for the first time, and it instantly struck a chord with me. My whole life I have tried to put myself into a position where I can negate the …ummm, less-than-optimal things about myself that I cannot seem to change. And if I’m honest, I don’t want to change some of them. We all have these character ‘flaws’, but that’s no reason they should either define us, or get in the way of our careers.

I don’t work on my weaknesses, I avoid them by focusing on my strengths.

The lucky few, the ones who knew from a very early age what they were going to be, will find the subject quote amusing or irrelevant, but for way too many us it hits close to the mark. Can you truly say that you are doing what you had intended all along, and are absolutely doing what you are on this Earth to do? No, neither can I.

A while back I postulated a theory that it’s actually OK not to have a passion in life, a true calling (nurse, fireman, teacher and so on), as long as you enjoy the things you ARE doing. These things are generally what I would call your talents. Skills can be learned, but you will only ever be REALLY good at something you have natural affinity toward. Nine times out of ten you will also enjoy doing the things at which you’re best, and avoid those you don’t do well.

Unfortunately, we rarely have the opportunity at work to completely ignore the things we don’t like, and may even end up being very good at something because a combination of our OTHER talents gives us an advantage.

For example, no-one who’s ever met me would accuse me of being a people-person, but my combined talents for simplification and strategic planning make me a very good consultant. Luckily I actually enjoy consulting, but even if I didn’t, I could very easily end up doing nothing BUT consulting for the rest my life because it provides an excellent living. Would I KEEP doing what I’m doing if I didn’t actually like it?

Probably, and that’s the point of this blog.

Now be honest with yourself, are you doing something you really, I mean REALLY enjoy, or are you doing something you found yourself good at? If the answer is yes, you’re in the second highest group of people in terms of living a good life. The only group slightly better off in my opinion are those making a living from their life-long passion. If the answer was no, and you only find your job tolerable, what makes you good at it? Do you know?

These are pretty much the only options open to you if you have to work, and this has nothing to do with how much/little you earn;

  • Your work is your passion
  • You make a living doing what you enjoy
  • You make a living doing what you’re good at
  • You make a living, don’t hate your job, but don’t enjoy it much either
  • You make a living and hate your job

As a complete guess, I would say that 90% of us are in the last 2, and probably because we assumed early on in our lives that without a passion there’s no point in trying. A total cop-out in my opinion, as doing what you enjoy AND what you are good at, is a VERY close second. This does not even involve a title, or a field of expertise, and you are not looking for a job as a something, you are looking for a job that entails the use of as many of your talents / skills as possible, regardless of what field you end up in.

I ended up in security, not because I have any particular interest in security itself (I don’t), but security just happens to provide the perfect environment for me to fully explore the things at which I excel (relatively :).

Anyone can do this, you just have to know what you’re good at. Like ending sentences on prepositions for example.

PCI – Going Beyond the Standard: Part 13, Secure Coding / SDLC

Once again, my ability to help out with this stuff is limited, but even my knowledge of what constitutes a good coding practice exceeds that of most organisations with whom I’ve worked.

The best phrase I’ve heard about the need for security relevant skills in coding is; “Applications are the gateways to your data.” So no matter how much network security you have, no matter how many controls you have in place, if your applications are insecure the bad guys get what they are after.

Functionality, and sometimes just appearances, often wins over the needs to build in security from the ground up. This is especially true with organisations who do not have the necessary skill-set in-house and are forced to outsource. The inability to conduct the right due diligence, as well as the usual budget constraints, combine to perpetuate the same vulnerabilities for quite literally decades.

Cross-Site Scripting (XSS) for example, has remained in the OWASP Top 10 since its first release back in 2004 (according to this site anyway), and has never dropped below 4th. How is that possible? With the enormous amount of information out there about how to code against this flaw, the answer is not that the bad guys are getting smarter (which they are), it’s that we are staying ignorant.

Ignorance is a choice.

As much as spending money on security is the last resort (in my opinion), few organisations have the luxury of maintaining a secure coding skill-sets in-house, meaning this must be outsourced. This is simple for web-hosting, just find a compliant provider for the services, custom apps however require a little more due diligence. Luckily all you have to do is ask the right questions. Oh, wait…

In a perfect world, your security needs would drive your budget, in reality, your budget determines what quality of service you can afford. To once again quote the cliche; You get what you pay for. Unfortunately, the competition in this field is so fierce, that organisation are almost forced to provide a crap service just to break even. It used to be that security testing involved a human being skilled in the arts of ethical hacking, now price compression is pushing everyone down the road of automation and good-enough-for-PCI-work.

So regardless of which development life cycle forms the foundation of your coding practices, it must include security at all stages. Let’s take the waterfall method as an example;



Security is built into no less than FIVE separate phases; Requirements, Design, Development, Testing and Monitoring, and this is in no way overboard.  Spiral, RAD, and Agile are no different, it’s just effected slightly differently.

In the end your WRITTEN life cycle must be taught to all parties, and followed explicitly, and strict separation of duties put in to place. This is not to say that you now need to hire ten more developers to meet the intent, but your checks and balances between the FUNCTIONS of the process need to show due care and attention.

Again, I’m no expert in this stuff, and there is really no way of going above and beyond here (not that going too far has EVER been an issue I’ve come across), but there is simply too much information out there, and too many talented security professionals, for there to be any excuses for not building appropriate security into your development life cycle.

Oh, and if you don’t use a code builder software (GitHub for example) to enforce the appropriate phases and authorisations, as well as effect the separation of test and production, you are already way behind the curve.

Finally, if all you use is the OWASP Top 10 as a checklist to test your web facing apps, you will be breached, it’s just a matter of time.

Not sure how to proceed? Ask.