Tag: Security Good Practices

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.

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;

waterfall

 

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.

Everyone loves toys, and IT/IS administrators are no different. However, it’s a very different thing to buy a new PlayStation for yourself, than it is to spend a considerable amount of your company’s money chasing after yet another buzz-phrase or a vendor-induced panic.

Worse than this is to mis-interpret a regulatory compliance standard (like PCI) and spend all your IT budget on technology, when the vast majority of these standards revolve around policy, procedure and standards. Like security should. Behind every security control, in every regulatory standard, is an intent, and until you have examined what that intent entails for your business, you simply have no justification buying anything.

Both IT and IT Security departments have only one purpose; to enable the business’s goals. That’s it. However, it the business’s responsibility to make those goals VERY clear, and fully support IT/IS when required. This does not happen without robust Risk Management process(es) maintained by a Governance Committee of some sort.

In every organisation for whom I have provided security guidance, they had the exact same dynamic; IT/IS massively overestimated their budgetary needs knowing full well the business side will reduce it as much as possible. Usually to point of making a lot of departments ineffective in any way that matters. Then things like PCI come along and suddenly IT/IS departments have ammunition to up their budgets to meet a supposed business requirement.

The smartest managers used this money to do things properly knowing that PCI compliance will fall out the back end of a security program done well. The majority however line up behind the security vendors like sheep buying exactly what PCI says. Every vendor of firewalls, anti-virus, DLP, FIM, IDS and all the other acronyms have made fortunes while the actual security posture in most organisations has barely improved, if at all.

Any consultant worth his/her salt has stopped a client from buying technology until they are satisfied that the client has the necessary processes in place to determine the ACTUAL need, perform a gap analysis, and exhausted all other options. That consultant also had in mind that buying ANY technology comes with a whole series of post-purchase events that must be complete in order to obtain any benefit from that purchase;

  1. Can existing staff actually USE the technology, or does some / all aspects of it’s running require outsourcing?;
  2. Does the product integrate seamlessly with the existing infrastructure management systems?;
  3. Is the increased security posture in-line with its on-going cost of ownership (management metrics)?;
  4. Has any thought been given to the products life cycle and future-proofing?;
  5. Does the product scale with the business?

…and so on.

The ages old (but still completely relevant) concept of Confidentiality, Integrity, and Availability (C.I.A.) ensures that every security program follows the law of negative returns; the more you have of one, the less you have of the others. This is equally true of the complexity of your program; the more complex your program, the less secure you are.

Technology has its place, no arguing that, but only technology in a business context is sustainable.

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

It is the job of every QSA to help their clients reduce their scope as much as humanly possible prior to inflicting the remainder of the assessment processes upon them. Even the very far from ideal Prioritised Approach from the SSC alludes to this in Milestone 1: Remove sensitive authentication data and limit data retention.

While the remainder of the Prioritized Approach can effectively be ignored, removing ANY sensitive data that is not required will automatically reduce risk. And once the redundant instances of data have been removed, hopefully the number of systems that transmit, process or store card holder data have been equally reduced.

The second part of the scoping exercise is to ensure that ONLY the systems in-scope for PCI are in-scope, and other systems which could be deemed in-scope-by-association are minimised.

There are 3 things that can put a system into scope for PCI:

  1. It directly transmits, processes or stores card holder data – obvious, and will include things like points of sale (POS), back-office servers, network devices and the like.
    o
  2. It’s in the same subnet / VLAN as a device that matches 1. above – not quite so obvious, and provides the greatest opportunity for scope reduction. e.g. you have 2 web servers in your DMZ but only one is relevant to e-commerce. By putting these servers in 2 completely separate VLANs, you can most likely take the non e-comm server out of scope entirely.
    o
  3. It has significant impact on a system that matches 1. or 2. above – This can include things like active directory / scanning servers / log servers / jump servers / system admin laptops and so on, and while they may never directly touch CHD, can significantly affect the security of ones that do. Being in-scope in this category does not necessarily put the other devices in the same subnet in scope, but you need to be careful here.

Unfortunately this is where most organisations start to make the biggest mistake in PCI; focusing on just the in-scope systems. Just because it’s no longer in scope, does NOT mean it should now be excluded from the processes necessary to bring the in-scope systems into compliance with what amounts to the barest minimum of security controls.

Not being in scope for PCI just means it’s a lower priority, and even then you can only make that determination if you have properly performed a Risk Assessment in conjunction with the company-wide data classification and asset management mechanisms. A good QSA will always ask for a risk assessment before they ask for a network diagram.

Segmentation to reduce scope should never, EVER, be exclusive to card holder data and PCI compliance, it should be part of an enterprise-wide project to ensure that all systems have the necessary level of protection per their data classification and their overall criticality ranking to the business.

Any effort to segment based on PCI should be appropriate, sustainable, and above all SIMPLE. Over the course of time organisations can grow organically with new business processes being tagged on to existing ones, and networks becoming more and more complex and ungainly. Unless these changes are implemented with simplicity in mind they can become rapidly unsustainable, and security itself goes out the window.

A good QSA will be able to determine scope and potentially some scope reduction options, a good CONSULTANT will be able to help you define your optimal network and segmentation infrastructure, so choose your help wisely.

Of the roughly 400 separate requirements in the PCI DSS, 46% of them require the review or examination of some form of documentation. From policy, to procedure, to configuration standard to diagram, a very significant chunk of achieving PCI compliance starts with paperwork.

How is it then that in the 10 years I’ve been performing PCI and PCI-esque assessments the ‘paperwork’ is almost invariably the last thing to close? I’ve seen large organisations get centralised logging in place before they managed to get their policies and procedures in order.

In Want REAL Information Security? Start With Your Policies I have already gone into why organisations should take polices and procedures more seriously, so I’m not going to repeat myself. But I will just say now that if you didn’t start your project to formalise your policies and procedures at the beginning of your assessment, stop, go back, and start there. A good QSA will fail you for crap policies just as quickly as they would for lack of encryption on stored card holder data.

All too often the client response to a request for documentation is to provide a handful of polices taken from the internet with the company name changed, but no effort whatsoever to customise the content in line with reality. Procedures are virtually non-existent, everything is in unprotected Word docs, several years old, and in no way standardised. The look on the faces of those being asked to provide just the location of the official copies is usually one of confusion, or worse, blank incomprehension.

The worst thing you can do is hand your QSA a bunch of crappy docs and say “You tell me what’s missing.” It does not work that way, and all you’ve done is thoroughly irritate someone who should be on your side. It is YOUR job as the client to tell the QSA which documents and specific language YOU think meets the intent of the DSS requirement testing procedures. The best way to do this (if you don’t have access to a GRC tool with DMS built-in, see below) is just to start with the DSS on a spreadsheet and map your existing documents to it. Your QSA will tell you the gaps, which gives you the necessary action items to begin your remediation.

Here’s the one I give my clients, help yourself; PCI DSS v3.0 – Document Mapping Matrix

Other stuff:

  • Policy Content – In terms of policies, procedures and standards, these are the major headings I generally expect to see; PCI DSS v3.0 – Policy & Procedure Checklist.
    o
  • Document Management System (DMS) – This does not have to be a major expense, a folder on an intranet share will suffice, but the point is to have a centralised location to place all of your latest approved documents. They should however have access control mechanisms in place to ensure only those with a real need to see them, can. Some of the more elaborate DMSs will take care of version control, ownership, review cycles and so on, as well as automated mappings to regulatory compliance regimes like PCI. Choose what’s right for your business, and look at the Governance Risk & Compliance tools that may have this built-in.
    o
  • Pre-Packaged Templates – There are many organisations that can offer pre-packaged policy templates, but none that can provide pre-packaged procedures. Best practice policies are numerous and can be customised to suit your business, but procedures are written by your organisation and are necessarily specific to it. Don’t buy anything claiming policies AND procedures out of the box, and don’t buy anything specific to PCI. Cover your business, and if you have to spend money to get your ‘paperwork’ together, focus more on expert guidance. Avoid policies that match the next two points.
    o
  • Monolithic vs. Modular – It is generally best to have each of your separate policies as stand alone documents with their own version history and ownership, a single policy document is very hard to maintain.
    o
  • PCI Relevance – The phrase ‘card holder data’ should appear only once, maybe twice, in all of your policies; in the Data Classification Policy. Every other policy refers to the classification in which card holder data was contained (e.g. Highly Confidential).

Like everything in security, getting policies right is not easy, but it is simple. There are many people out there who can help you if you don’t know where to start, and this is not something you should do half-arsed.

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