PKF AvantEdge

Category: Technology (Page 5 of 11)

PCI-DSS: Internal Audit Signoffs

April 17, 2019 / / 0 Comments

After going through previously the nightmare of PCI-DSS Certificates, as described with considerable detail in our writeup previously, we are now faced with a new phenomenon called the Internal Audit Signoff, which is further confusing our clients.

OK, first of all, let’s do a brief recap.

How are 3 ways that PCI-DSS can be validated?

Answer :

  1. Full Report of Compliance (RoC) from QSA – Level 1 Service Providers, Level 1 Merchants
  2. Self Assessment Questionnaire (SAQ) signed off by QSA/ISA – Level 2 Merchants, (Maybe) Level 2 Service Providers
  3. Self Assessment Questionnaire (SAQ) signed off only by Merchant/Service provider – Level 3,4 Merchant, (Maybe) Level 2 Service providers

Those are the 3 endgames for PCI. And of course, the end scenario called Failure, or non-Compliance. But that isn’t cool, unless you are the type who is happy with Thanos snapping his fingers being the definite end to all things.

Now we all know item 1) requires the participation of a third party QSA/ISA to signoff on the Report of Compliance and the Attestation of Compliance. ISA here is internal security auditor. We won’t touch it this round, because this requires a whole new library of articles to discuss.

Item 2) likewise requires a third party QSA/ISA to signoff on the Self Assessment Questionnaire and the Attestation of Compliance.

Item 3) is basically, self signed – not a lot of acquirers take this seriously as basically, its anyone signing off anything they feel like. There is no validation, and sometimes, it’s akin to the CxO sticking a finger to the tongue and putting it up in the air and going, “Yeah, that feels ’bout right. Let’s sign off and say we have these controls!”

Let’s talk about item 1 and item 2.

In item 1, it’s a gimme that the QSA needs to go onsite to the locations to do an audit. I have never heard of any QSA signing off on a full RoC without actually going onsite. Maybe when our tech reaches a point where the QSA can be holographically present in a location and see what’s there without being physically there like a Jedi Force Ghost, that the PCI-SSC would accept the signoff. But by then, we could probably just tell PCI-SSC that these aren’t the companies they are looking for, and then there’s no need to do PCI.

Until then – the question is for item 2, for the QSA to signoff the SAQ, must they be onsite or they can provide a remote signoff?

Now if you ask a QSA what is the difference between 1) and 2), they would say, not much – except they don’t have to waste their time writing the tome called the Report of Compliance (ROC) for level 2. Level 2 is basically a judgement made by the QSA based on existing evidences that what is stated in the SAQ is true, or at least as much as they can have reasonable assurance on. The SAQ is not a document written by the QSA, although they can help, but in this case they are validating it. For Level 1, it’s a different story. They have to write the RoC and the work put into that reporting phase is surprisingly a lot. In comparison, it’s probably like reviewing a first term essay paper written by your senior students (SAQ Validation) versus writing the Silmarillion including the index (RoC).

However, for QSAs to conduct their audit and provide a fair opinion on the controls, they will still want to be onsite for option 2), much to the chagrin of many of my customers. Their argument here is: “Hey I am level 2, why must you come onsite??” And again, the crescendo grows that a Level 2 should have less things to worry about than Level 1 – another myth as old as us telling our children not to sleep with wet hair or else they will wake up with a storming headache.

To get to the bottom of this, we got directly from the horse’s mouth (in this case from Mastercard SDP program response: “In this scenario (describing item 2) the QSA has to be onsite. The QSA cannot simply review a RoC or SAQ without being at the location to validate that controls are actually in place.”

To be fair, the above discussion was applied to L2 Merchants (Level 2 Merchants) – those making more than 1 million volume card transactions per annum. Whether the QSA is willing to take the risk and perform an offsite review for a Level 3 or level 4, I wouldn’t know – that’s up to the QSA and the card brands I suppose. But to be absolutely safe, we would advice that all levels should be treated as such – if you need a QSA to signoff, that QSA needs to be onsite to get it done. Or use the Jedi Force Ghost. Both are acceptable to PCI-SSC I am pretty sure.

So, as an illustration, we had a request from a company, requesting us, for their location, to get the QSA to signoff remotely. Because “The Other QSA did it for us and certified us”. The other QSA meaning someone they engaged earlier.

OK – this certification term again. I am sure that did not happen – but many use the word certification for anything: actual RoC, doing the SAQ with QSA, signoff on SAQ by themselves, getting ASV scan etc…those are typical scenarios we see this certification word being thrown.

Digging further, we received a worksheet which was a typical ‘Scope’ document (you know, where they ask what sort of merchant you are, what business, how many locations, devices, whether you store card etc), and the instruction was to fill this up, send it over to the QSA and the QSA will ‘sign off’ their PCI-DSS compliance, all within 2 weeks.

QSA certified within 2 weeks, remotely, and with just the scope document, without validating any controls? No penetration testing or ASV? No Risk assessment? No review of information security policy? How?

We asked for the copy of the official signoff page (Section 3c of the AoC) but instead we got a signoff on a report from QSA stating what was scoped in and what was scoped out of PCI-DSS. A typical scope document. It’s a useful document, but it’s not a document required by the PCI SSC. In fact it doesn’t serve any purpose other than to simply state what is in scope for PCI-DSS based on the scope questionnaire (not the SAQ) provided by the QSA.

I am 100% sure the QSA meant well by this, but the problem was, there are interpretation issues. We cannot expect clients to right off the bat understand PCI-DSS and all it’s seemingly malarkey documents – the AoC, the RoC, the 9 different SAQs, the ASV scans, the partridge in the pear tree etc. So when we asked for a SAQ signed off by QSA, of course, clients will fall back to any document being signed off by QSAs. That’s why we are not big fans of the practice where clients are provided by ASV certificates just because they passed their ASV scans. They all think they are PCI certified because they have a QSA signed off document which is the ASV ‘certificate’! And the same here goes, this is simply a scope review document – almost like an internal audit report, that does not make a company PCI compliant. In fact, it is just confirming that the company MUST be PCI compliant according to the scope set.

So the moral of this story is: Not all QSA-signed off documents are valid documents for PCI-DSS. ASV scans, while valid, doesn’t make you PCI compliant. It’s only a small percentage of what you must do. Internal Audits or scope reviews like the one we saw, even signed off by the QSA, are not valid PCI-DSS documents. They do not make you PCI compliant. As PCI has explicitly stated before, the only valid PCI-SSC documentation are the AoC, SAQ, RoC and ASV scan reports (not certificates, with flowery borders and impressive cursive fonts in gold). Anything else are supplementary materials used to support the compliance, not to validate it.

For more clarity on PCI, drop us an email at pcidss@pkfmalaysia.com. We will try to sort any issues you have, and yes, we are the company you are looking for.

The Service Provider Conundrum

March 28, 2019 / / 0 Comments

This is probably the umpteenth time I am writing this, but again we need to clarify once more on how Service Providers that do not store, process or transmit credit cards come in scope for PCI-DSS.

I just finished a very testy call with a multi-factor authentication cloud provider (actually he is a reseller/distributor), who called us back on our enquiry whether his cloud service is PCI compliant or not. He said he doesn’t need to be but their solution will help our clients in becoming compliant. If I get a dollar everytime this argument is punched out, I will be retired in the Bahamas by now.

Now, to be fair, almost everyone thinks like this. “If we do not store, process or have any credit card processes, we don’t need to be PCI compliant.” It may be like this in the past, but unfortunately, QSAs are tightening up their definitions of service providers and cover what we now deem as having ‘security influence’ over CDE .

So yes, you technically have nothing to do with credit card of your clients, but let’s say your client authenticates to your CLOUD solution to get multi factor authentication to access their CDE. Let’s say you are having a bad day and you get compromised, and the attacker hijacks your cloud and provide a counterfeit token attack similar to what was suspected to have occured on the RSA SecurID breach in 2011. Would a scenario like this equate to a CDE compromise? Would this mean your service is actually having security influence over CDE?

I could have explained this to the earnest reseller on the other end of the call. But I was fighting a fever, cough and flu all thrown in one large ball of crappiness that made my mood not so great. And the fact that he sounded a little patronizing when he said, “Oh, you are very confused. We don’t need PCI-DSS, so maybe you need to understand the standard a bit more.”

Hey, Captain, I’ve been living in this PCI crap for the past 8 years. I wish I didn’t understand it as much as I do right now to be honest because then I can always plead ignorance when questions like these pop up. As it is with all who are cursed with knowledge, I now have to trudge this lonely path of patronizing, condescending and almost pitiful responses to my queries as I had to on this very sick morning.

So, QSAs are lumping MFAs cloud solutions as critical security functions. To be fair to these QSAs, PCI did identify the following to be in scope:

“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of its PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in PCI DSS scope.”

We always assumed we were talking about authentication as in AD, or LDAP and never thought of lumping multi factor ‘authentication’ into authentication servers. But think about it. If you have an onpremise MFA solution in your data center, would that be under scope for PCI-DSS, if its used for access to get into CDE? How different would it be from AD or LDAP, which manages one factor of authentication (something you know). Wouldn’t the other factor also need to be looked into? (Something you have or something you are).

In the same argument, thus QSAs conclude that if there is an authentication in the cloud, regardless of which factor, that authentication service is in scope of PCI-DSS. Same goes for logging and monitoring service providers.

So what’s there left for customers using MFAs cloud providers to do?

Well, there are two options.

  • For providers that have undergone their own PCI DSS assessment: request and review the Attestation of compliance, scope, date
  • For providers that have not undergone their own PCI DSS assessment: include the provider’s environment as part of the entity PCI DSS assessment (increase your own assessment scope). You may need to request your own QSA to perform the provider’s review (tough… preferred solution is to work with providers able to demonstrate their PCI DSS compliance with their own assessment)

I am afraid it is what it is.

After getting sermonized by the (I believe, well intentioned, though somewhat with such poor communication skills) cloud MFA reseller, I thought writing all this down will save me the agony of going through over the phone to explain this particular situation. In that conversation, I just asked him, “Is your solution PCI Compliant or not?” and never really got him to answer properly because he kept arguing the fact that I am completely missing what PCI-DSS is all about.

Knowing it was impossible to argue on this point, I finally said, “Thank you so much for your time, I will let you know when I need more clarifications.” And away his solution went, lumped within the 20 others in my bin called “Non Compliant MFAs”. The search goes on, and looking forward to more patronizing put-downs from well-intentioned resellers. Hopefully this article goes some was in clarifying without anyone getting jumpy on us.

If you need more information on PCI-DSS or any other compliance standards for that matter, let us know and drop us an email at avantedge@pkfmalaysia.com

The Sickness of Busyness

February 6, 2019 / / 0 Comments

I’ll admit it.

Like any other companies, or culture within the company, we have our own little sayings to describe certain situations, certain issues or certain people. There is the often used phrase of FOMO – Fear of Missing Out, a situation where a person is so afraid to be losing out on things that they need to be involved with everything. There is the usual phrase of NRS – New Recruit Syndrome, where a newcomer becomes so enamored with making things ‘happen’ in the company that suddenly everything seems to be moving — until it stops again. There is also the term LLB, not to be confused with the Bachelor of Law – “Look Like Busy”. It’s basically to describe someone who always seem to be rushing, to be going someplace, to be doing something, to be typing things in their handphone, to be always sitting down as if their ass is on fire, to be talking on the phone with their bluetooth headset while walking around, making them look like they are doing a soliloquy in Shakespeare’s Hamlet.

With the advent of the mobile phone, the ultimate personal and intimate device, this LLB has taken into another dimension. Admittedly, as consultants, we do fall into the trap of being busy many times over. There are often remarks made to me: “You seem to be busy all the time.” The truth is, yes, sometimes I am rushing from one meeting to the next. Sometimes, I need to just get into my car, and in between meetings, I am on the phone to finish off another meeting. Yes, sometimes, we overbook ourselves because client A doesn’t come back to me and I booked in Client B and then Client A says OK, let’s do a meeting and I go, Ah Crap, can we move yours an hour later. Client A goes, “Wah So busy one ah?” and Client B, when I am rushing to finish off the meeting so I can go to Client A, goes “Wah So busy one ah?”. I think 80% of this LLB occurs because my daily schedule sometimes end up so dynamic, as in, random clients may need to meet for whatever reason – and to top it off, we don’t have dedicated sales, so many times we are doing marketing, meeting, administration, auditing, operational support etc.

But LLB isn’t about actually being busy – it’s about looking or being busy even when we are not. And that’s the truth. We are sometimes accustomed with being so caught up with things, we just think it’s unnatural to actually have….time.

Think about it. How often do we actually sit down over lunch/dinner and not whip our phone out, even when we are not working on anything? Or at the traffic lights or caught in a jam? Or when we are having coffee alone? Or when we are waiting for the one guy who is always late for meeting and we all sit around tapping away our phone. Truth: I’ve actually seen a client who, while waiting for the meeting to start, take up his phone and just started tracing his finger over his phone in circles while staring at it. He wasn’t reading anything. He didn’t have any app started. He wasn’t listening to Spotify. He was, in a trancelike way, just tracing his finder in tiny circles over his LOCKED screen.

What?

How dependent have we become to this tiny little device we always have in our pocket? How often do we go absolutely ape*hit when we cannot find our phone? How often do we actually place this guy on the table in our meetings, in our lunches, in our time even with our family? Have we become so consumed with the idea that WE ARE NEEDED that we think we are needed even when WE ARE NOT?

Once, during an interview, a guy I was talking to kept checking his phone. Maybe he was nervous, OK, I’ll hand him that. But he kept looking at his phone until I finally asked: “Is your boss looking for you?” and he looked at me in a confused manner and I just shook his hands, said, “Thank you for your time to sit down with me” and I left. Oh, yeah, I was the one interviewing and he was the interviewee.

What is wrong with us? Are we so disillusioned with our own importance that we can’t even for a single minute stop this nonsense of tapping on the phone, writing an email, drafting a report, reviewing a document or composing a stupid blog post and just look up and find that we are still human?

One of the things we need to change, starting from our own, in this LLB business:

a) Meetings – if you are meeting a client, or meeting a service provider, or meeting a colleague, make it a point to limit the phone usage. It’s highly insulting that during a one on one meeting, while it’s going on, that you whip our your phone and tap an email or a reply to a chat. If you have to do so, such as answer a call, excuse yourself and say, “I am so sorry. I need to take this just for a while” and then tell the other side that you would call them back. Don’t take any longer than necessary. Of course, there are exceptions. Once I was with an important client and my mother called. She never calls during work hours unless it was an emergency, so these were exceptional circumstances. I took it, but I apologised first to the client. The concept is simple: if someone actually takes time to spend time with you, give them the due courtesy of your own time with them. Except for these exceptional circumstances, let’s have conversations and connections, as opposed to emailing or texting.

Another irritating habit (of which sometimes I am also culpable) is the constant tapping of the laptop during a meeting. This is usually done by non-leads (the guy in the meeting that is not participating much in terms of discussion). Unless they are doing minutes or capturing the discussion, this is strictly banned in our company. I had a client once who told off his executive to get out when he was tapping furiously on the keyboard while the meeting was going on, and it wasn’t related at all to the discussion. He was thinking to solve an operational issue or sending out an email to another client. No, his boss was saying. You aren’t that important. Get that in your head and sit down and shut the hell up and listen and learn. Good lesson, that one.

b) Mealtimes– Even lunch or dinner with colleagues, It’s very irritating to have the phone out the whole time. Don’t. Everytime you do that, it states that the people around you are unimportant. In our family, we try never to do have that. Yes. Even when I am bored stiff staring while my 3 year old is taking his own sweet time eating his food (he likes to eat on his own but by the time he finishes, fishes have actually evolved into birds) – and my wife and my other kid are no where to be found in the shopping mall, I have to refrain from whipping out my phone, unless it’s a call. Mealtimes are no-no for phones for us in our family. Why not during our corporate lunches/mealtimes as well? Why not interact without the laptop?

c) Travelling– Yes, I admit, caught in horrendous traffic, it is very enticing to catch up on things. I’ve avoided this (because of traffic summonses) primarily by either having a meeting in the car (yes, I am theoretically still using the phone) or just listening to Spotify, which is a God Sent to road warriors who spend half their day stuck in traffic. If I am with another colleague in the car, then getting on the phone is a no-no (also because some meetings are obviously confidential). Let’s interact instead! In the lift, don’t whip out your phone and tap around or continue talking. In the toilet, for God’s gracious sakes, don’t talk on the phone while you take a dump! I’ve heard this many times before. There are practical reasons not to do these things – primarily because of confidential information being accidentally leaked out – but also – come on, it’s crazy having to chit chat while doing something in the toilet.

Tell ourselves: I am not that important. Yes. This goes against all the motivation, self improvement philosophies that keep saying to us how important we are etc. No. We are not that important. Life for other people will still continue on if I don’t respond in an hour or so. While it is common courtesy to respond to a text or email within a reasonable time, nobody is saying you need to respond immediately. I mean, back in our father’s time, they didn’t have email. How on earth are they supposed to reply “yes” to lunch immediately? So unless it’s life and death and remarkably exceptional circumstances, sometimes it’s ok to put the phone down.

But take note. Many times, busy-ness occurs to us because we are poor time managers. When we promise a deadline and we miss it, and we complain because now our boss is calling us, and we go: well, family time more important, let me tell him to screw off. That’s also stupid, and will probably cost you your job. If you don’t do something or did not hand in something, then take ownership of it and do it. And doing something doesn’t mean just finishing it. It means finishing it with the proper quality required. I’ve seen many so-called reports on my table that could have been better written by llamas. As in the animal in Tibet. If you can’t get your work done, then be prepared to work over time, over weekend to fix or finish it and don’t complain about it. Deadlines are deadlines. It has nothing to do with looking like busy – it’s our own fault for not being good time and quality managers.

LLB isn’t about that. It’s about Looking Like Busy even when we are not. It’s about: Oh, let me stay up late tonight just to show everyone I am working late and send out an email at 4 am to impress my boss. It doesn’t matter what time you work until – some people like me work best between midnight at 4 am, so that’s when we get stuff done. It doesn’t mean that I send an email out at 5 am, I immediately get my morning off!

We should take our time to look around us. Observe. Even in our workplace – it’s almost like a family since that’s where we spend most of our daily hours. We can observe nuances of a person, how someone reacts, the way he or she speaks – human connection is being lost in the new generation of logical and virtual connectivity. Crack a joke. Laugh. Remind ourselves of the humanity of life.

I am often reminded of how precious little time we have on earth when I am with my children. I am reminded of a time not very long ago when I was their age, looking up at my dad as he waited for me to finish my damn meal, but (because there were no mobile phones back then I guess), still grinning at me as I attempted the foolish task of manipulating noodles into my mouth with a spoon. And suddenly I am here. Same situation, looking at a mini version of me doing the same thing and taking so much of my precious LLB time.

Are we really, truly that busy, or are we just needing to vindicate our importance on this planet before our clock is up? Our importance isn’t in the glowing screen of emails or Whatsapp messages or Facebook Likes. Our importance is in the reflection of ourselves in the eyes of our children. Our parents. Our spouses. Our friends. Or in many cases, even our pets. It doesn’t matter “who”, as long as it’s not a “what” that’s reflecting back at us.

So, enough of writing this blog post for now. I am not busy now and I don’t want to appear to be busy. There will be times when I am, for sure, so I’ll enjoy the times I am not. It’s time to get some coffee and converse with someone – or just look at my kid and wait for fishes to evolve to birds. Say no to LLB this year! Happy new year!

Proxies in PCI

May 4, 2018 / / 0 Comments

A proxy server is a server that serves as an intermediary between the requester (a client PC for example) and the responder (typically the destination server). There are 3 types of proxy servers that are commonly implemented in many organisations:

  1. Forward proxy – this is the most common proxy server. A forward proxy is a proxy server that serves the request of the internal client and processes the request for the client by sending and receiving the response from the destination server. In the most common implementation, it is an ‘internet facing’ server that will retrieve internet resources and return it to the requesting client. How is this useful? For one, it serves as a single point for security access control. If you have hundreds of systems coming through your firewall asking for a thousand of requests per second, a proxy can do a few things. It can control who gets what access. Additionally, if implemented with caching capability, a thousand requests for the new Beyonce video don’t need to get that video downloaded a thousand times. I can cache within the proxy and serve it up internally. Cool!
  2. Reverse proxy – Reverse proxy is the opposite of a forward proxy in terms of traffic flow. It is allowing what can access your internal resources. Again, it is an external facing proxy server that accepts request from an external requester and sends the request to the internal servers (for instance, an FTP, HTTP or SMTP server). The response returned to the requester will be as if it was coming from the proxy server. There are few objectives for reverse proxy e.g. shielding the internal servers from the outsider, load balancing, security controls etc.  It’s fairly easy to set up as well.
  3. Transparent proxy – transparent proxy is a proxy server that sits between the requester (client) and responder (server) and there is no configuration required on the client side. A transparent proxy is generally deployed inline, meaning, between the client to whichever gateway it is going to . It intercepts the client request before forwarding it to the destination, without the knowledge of the client. This is useful if you have thousands of systems, and limited control, or you just don’t like group policies from AD. Transparent proxy normally is used as a content filtering,  Internet traffic control and web caching.

Is a proxy server useful when it comes to remediation for your PCI DSS compliance? Yes it is . There could be some cost saving scenarios where a proxy server is useful.

Where can proxy server applies? An example: a client is running MariaDB on a  Linux server and using clamAV  for malware protection and they have a database storing credit card number (FULL PAN). Obviously, this server will be in a CDE “in scope” segment (Card Holder Data Environment in-scope).

In PCI DSS 3.2   Requirements and Security Assessment Procedures requirement 1.2.1 and 1.3.4, while it states that the traffic coming and going out from the CDE must be restricted, it does not state that you cannot have an outbound traffic from a CDE to the Internet. Below is the reference to the PCI DSS for inbound and outbound traffic to/from CDE:

1.2.1 Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.

Specifically INBOUND:

1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.

1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.

And OUTBOUND:

1.3.4 Do not allow unauthorized outbound traffic from the cardholder data environment to the Internet.

On proper reading, inbound traffic is a strict no-no for Internet to CDE. So either you tackle this with an intermediate server in the DMZ, or a reverse proxy can come in play.

Outbound is a little more flexible, whereby all traffic should be restricted

Restricted isn’t prohibited, but there is a good reason why proxies become useful here.

a) It’s better that organisations do not to expose their CDE systems to the Internet, even for outbound. This makes sense, even though in most cases you will likely NAT your outbound connections through your firewall. But try arguing this with your QSA and you will probably wish you had just implemented controls instead.

b) Firewall policy minimisation. Why? Because you need to do a firewall review. Imagine you have 50 systems in your CDE requiring patches or connectivity to external. You would need to have a policy that adds/removes these systems to specific ports, destination etc on your firewall. With a proxy, you deal with one IP going out.

So for the above example, if the client can’t expose their CDE segment to Internet, a forward proxy can be set up. Setup a proxy server (e.g. Apache, etc) in the DMZ (in scope) segment. Configure the database server to point to the proxy server. With this setup the database will be able to get the antivirus update through the proxy server but without connecting directly to the internet. The proxy server serves as the intermediary between the database server and the internet. The QSA is happy and everyone passes PCI.

In this example, implementing a proxy server is not the only method that can be used to connect to the internet and have antivrus getting the update. You can set up a ‘repository’ server in a non-CDE, in scope environment which will then download the antivirus updates and patterns and the CDE server pulls the updates from this server (like WSUS for Windows). As in many things PCI, or obtaining the latest Beyonce video online, there are a few ways to skin a cat.

Contact us on pcidss@pkfmalaysia.com for more information on how we can help your PCI-DSS program!

 

Penetration Testing and Vulnerability Scans

March 27, 2018 / / 0 Comments

In our compliance services, oftentimes, we are tasked to assist our clients in security testing – either conducting those ourselves, or to verify previously conducted tests for compliance purposes. There are many occasions where clients decide to perform the scanning on their own, aside from the obvious option of engaging another party to do this. When we receive the test reports from our client to verify, that’s when the excitement begins.

The fundamental question we often face is, what should a penetration testing report look like? What does a vulnerability scan looks like? This age old question has been haunting PCI-DSS for years, so much so that the council decided to publish a guidance on this, found: https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf

It’s a good read, if not fairly simplified, but it seeks valiantly to answer the question of what is a penetration testing vs vulnerability scans. This is important, because in PCI-DSS, the latter needs to be done quarterly, while the former needs to be done annually. When you multiply that by the costs and number of assets in scope, we could be looking at a decision involving tens of thousands of dollars.

In the document, section 2.1 dives into this and attempts to seek a differentiation between these two. In the basic concept of penetration testing methodology, these two activities serve specific purposes, for instance in the activities of Discovery, Enumeration, Footprinting, Exploitation, Cleanup etc, depending on which approach you take. And while there are many ways to explain the differences, to summarise:

A penetration test can be a vulnerability assessment (or scan, we will use interchangeably for the sake of this article) and beyond, while a vulnerability scan is not a penetration test.

A Penetration test can be initiated with a vulnerability assessment. The result from the vulnerability assessment will be used by the tester to penetrate or perform a more detailed assessment to circumvent controls or exploit the discovered vulnerabilities. In the process, the tester will also use manual methods to “test” the vulnerable system and likely during this process of poking around, discover more vulnerabilities or loopholes in the system that may not be detected during the initial scan. In the presentation of the findings of a penetration testing report, typically the ‘Proof of Concept’ (POC) detailing how the vulnerability was exploited will be documented.

Vulnerability assessment is the process to find out known vulnerabilities by using an (oftentimes) automated method (such as scanning software or scripts) against the targeted system. The result of the scanning will detail down the vulnerabilities, the risk exposures and action that can be taken to remediate these vulnerabilities. There is typically no manual proof of concepts that is done in the penetration test. The objective of a vulnerability assessment is to discover and report known vulnerabilities, not to exploit them.

A penetration test will normally take longer time to complete, i.e. few days, considering the manual verification or activities that need to be carried out to ‘penetrate’ the vulnerabilities. A vulnerability assessment can be completed in a shorter time frame, depending on the size of scope and software installed on the target system and it can be run on automated or scheduled basis. In our vulnerability scans, we also refine the results further by eliminating false positives, such as a patch that might not have been applied, but other secondary controls like virtual patching are in place to mitigate the risks. In either case, these are different activities, and in PCI, we need to understand what is NOT Penetration Testing.

We once received a 250 page report from our client who proudly said this was a professional work done by an outsourced security testing company offshore. Surprised as such a tome, which we assumed must have excerpts of Tolkien’s Lord of The Rings in there for good measure – we went through it. We found that it was nothing more than a raw report of the entire software inventory of the entire scope of around 50 plus assets. Meaning it listed down in excruciating detail what are the software installed in each of these systems, the licenses the OS versions etc. It was nothing more than a dump of the system’s software and nothing more. Not even the courtesy vulnerability scan. We told our bright eyed customer that we cannot accept this, and while this is a good book to have in terms of detailing the software they have, it has nothing to do with penetration testing, or vulnerability assessment. From singing praises of the offshore company, he ended up throwing them invectives that would make a pirate cringe.

We do need to be careful. We are not saying that the entire industry is filled with such charlatans peddling so called pentest services for a song and giving you a report that only provides you with the figurative emperor’s clothing for your security needs…but we must be able to differentiate what is, and what is not, security testing.

If you have further questions on security testing, drop us a note at avantedge@pkfmalaysia.com and we can quickly assess your needs and advice you on your next options to take.

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑