PKF AvantEdge

Tag: PCI-DSS (Page 5 of 10)

PCI-DSS: Business Not As Usual

June 21, 2018 / / 0 Comments

Have you heard the phrase Too Long, Didn’t Read? What if this applies to your PCI DSS compliance program, rephrased to “Too administrative, didn’t’ do?”.

We get this all the time in our meetings. Everyone mobilise for the big PCI project, everyone celebrates when they get certified and everyone suddenly gets collective amnesia and forgets about it. They forget there are daily requirements (like daily review of logs), weekly requirements (like FIM file comparisons), monthly (like critical patching), quarterly (ASV etc), half yearly (firewall reviews etc) and annual (testing etc). Yes, there are such requirements. We generally encourage our client to celebrate their success for first time certification but keeping in mind these obligations. Certain things you just can’t afford to miss out like your ASV scans and Internal VA scans.

PCI calls this Business As Usual (BAU). Being so long on the receiving end of these compliance requirements and now dishing it out in our advisory, I can safely say: PCI isn’t business as usual. In theory, yes, it should be, but theory and reality remains as far away as the possibility of Malaysia winning the next World Cup. A lot of our clients, after winning the PCI certification, find themselves completely overwhelmed with the so called Business As Usual theory that they wonder, whether after achieving PCI Business As Usual whether there will be any Business left to be usual about.

So what happens now that you are PCI compliant? When you are planning your PCI DSS compliance maintenance, you may want to setup a team to look into all the requirements, be it the technology, process and people. After you get your PCI DSS compliance, remember, the ‘maintenance’ clock starts. Yes. So if you take 2 months to celebrate your victory over this dastardly villain called PCI, you technically have one month left to do your Internal Scans and ASV scans. So don’t forget about what you need to do. Your PCI team needn’t be dedicated personnel (Very few companies can afford that), but there should be a lead person, relatively not bogged down by day to day operation works, and ideally independent from the operations as well. If you have a info sec team, it would be good, else a technical project manager to lead and the responsibilities to maintain, to go back to the process or system owners.

True, even before PCI arrives, you are probably already bogged down by other compliance requirements on top of your normal day to day. ISMS, customer audits, regulatory audits and assessments, internal audit, and now PCI. It’s like eating pancakes after pancakes except these are horrible tasting pancakes.  You might forget some of the administrative tasks that need to be maintained as part of your PCI DSS compliance process and we have had customers scrambling to complete their quarterly scans after missing them. Eventually, after a period of time, all these tasks will pile up on your plate and you are left with the prospect of being unable to be recertified. Your PCI DSS compliance will be at risk of becoming non-compliant and void and really, it’s not something the board will be too happy about, after taking 3 months of budget to celebrate the victory earlier. It’s like winning the English Premier League one season and getting relegated the next. The emotions are too much. We may think these maintenance tasks are petty but it is an important component in your PCI DSS compliance ecosystem.

Here are some insights to some examples of these administrative tasks that might be missed:

Changes on firewall/switch/router rules or configuration– it is highly critical that before a change is done, proper testing, approval and documentation are carried out. As these devices are critical components in the network infrastructure, any misconfiguration may result in security issues or in our observation, even bring down the whole network and have people scrambling over the weekend unnecessarily. Proper testing and approval process are any case required before changes can be made and this must be documented. Documentation provides an audit trail of changes and why these changes are required. So, don’t forget to document this process. Or risk the weekend being messed up.

Patching – There is this perception that if I’ve setup my systems to perform patching automatically, everything is well. Wrong! You need to review the patches and ensure that it is safe to be deployed and it will not like, I don’t know – crash your production systems? Next is to make sure the patching applied is being documented so that you have a history of updates on your system. A configuration information (CI) system can do that, or you can ensure you run your inventory checks regularly, as Windows would keep track of these applied patches. If the system is being patched up manually, you need to have the procedure of checking for updates on a regular basis. Make it a habit to check if your system is running with the latest patches regardless if the patching is automatic or manual by making it as a checking activity in your periodic task list. Remember, PCI would require a one month critical patch deadline and three months for non critical security patches.

Anti-malware – anti-malware will normally update automatically and periodically and we will assume that it will run as what it is being configured to do. As such we will not bother to check unless something bad occurs (which almost always does). As part of your administrative task, you should make it as a daily task to check the anti-malware system status, malware detected and the resolution of it and put this task in your checklist.

Logging and Monitoring – PCI DSS requirement 10.6.1 requires review of security events at least on daily basis. Most people stare blankly at me as if I’ve just told them elephants do wear tutus and can fly. Then they realise that I am not joking, they shake their head and invariably say (in variable tones, depending on how incredulous or stupefied they are): “WHAT?! DAILY?!?” .

Well, yes, in a way, although PCI in its supplementary document Effective-Daily-Log-Monitoring-Guidance.pdf, they have provided this little leeway for your ease:

“A reasonable timeline must be defined to allow less capable organizations to perform security log reviews while still enabling the organization to detect malicious or anomalous activity before it can likely escalate. In the case of Requirement 10.6.1, PCI DSS has determined that timeline to be a maximum of 24 hours or one calendar day.”

So when we refer to ‘daily”, it is with this definition in mind. Still a difficult one, but hey, OK.  In our advisory works, we have seen that clients often miss out the daily review and alert they receive (usually through email). It could be a SIEM (Security Information and Event Monitoring) system is deployed and configured to identify a threat and sends out an email to the person in charge. Instead of monitoring this email that might be a critical security issue, it is not reviewed. Not reviewing security alerts is a risk that may have adverse effect for obvious reason. In a recent retailer breach, for many months hackers were siphoning information from their POS systems to a spool server and removing that data file to an external system. If reviewed properly, such an abnormal data flow might have been spotted.

So, these are a few of the admin tasks. There are a lot more. Moving forward, be diligent, make it a habit to not miss any of these out and incorporate these administrative tasks as part of your daily routine tasks. Other tasks include ensuring quarterly testing such as ASV, annual penetration testing, etc as described in requirement 11 are carried out properly and given enough time to perform. Don’t expect your team or vendor to do a pentest on 50 systems and tell them to complete it by tomorrow. Failure to observe PCI timelines may result in you losing your compliance.

Don’t get relegated after winning the league!

Contact us at pcidss@pkfmalaysia.com for further queries on PCI-DSS and we will set up a meeting with you as soon as you are available.

PCI and the art of scoping

May 5, 2018 / / 0 Comments

A lot of people we have met had told us this: “Since we are ISO27001, PCI should be a piece of cake, right?”

The context of this is because ISO27001 and PCI are often seen as distant cousins. They are both very relevant in our country and region (unlike other compliance like HIPAA), both deal with information security, and the overlaps between the Annex A controls of ISMS and PCI are evident. Therefore, the natural conclusion is ISO27001 is either a superset or a subset of PCI-DSS.

The problem with this assumption begins right at the start. In ISO, the scoping is largely determined by information that matters to your business. Before the iteration of 2013, scoping was generally done in a cowboy sort of manner. We met a company who had tons of sensitive information and told us they were ISO27001 compliant – and their scope was the security of their printing documents. Yes. How they literally secured the hard copies of the printouts. That was their scope statement.

Now 2013 version of ISO27001 had tried to stem these shenanigans by introducing interfaces and dependencies. Basically now the scope needs to cover information that are deemed important enough to protect from business perspective. This would cover the products and services relevant to the context of the organisation. Overall, scope determination of the ISMS can be a prolonged matter if you have a large organisation, and is often subjected to the business side of the organisation.

PCI scope?

It’s determined by the information that matters to the payment card brands, not your organisation. Credit Card Information. Primary Account Number. That’s it.

If you store, transmit and process PAN, PCI applies. If you don’t do any of these, and you do not influence any transactions in the payment card flow, then PCI doesn’t apply.

Often, people express utter shock that PCI doesn’t have any business continuity requirements. In terms of the holy trinity of information security – Confidentiality, Integrity and Availability (CIA), PCI primarily focuses on Confidentiality. Integrity is only focused in terms of its relation to confidentiality (Integrity of logs, integrity of system changes, system files etc), and there is no concern on Availability. Which makes sense. Between you closing down your business for one week versus you losing credit card information of your customers, the latter is viewed as more critical to the payment brands than the former. Although from a business perspective, a loss of business for a merchant is a loss of business for the entire data flow, upstream or downstream, so PCI not really caring about your RTO or RPO may be counter productive – but that’s an argument for another day.

At the end PCI scope boils down to you storing, transmitting or processing card holder data (CHD). Even if you don’t do any of these 3, you might still be in scope if you influence the security – an example would be those SAQ A e-commerce merchants that redirects requests to another PCI service provider. Even though they don’t deal with the CHD, they influence the transaction through their redirects, therefore, some parts of the requirements need to be met.

So – before we start our PCI journey, it is  very important to know what is the scope that is covered in your PCI environment. We may not want to take the whole environment as IN SCOPE – for cost, quality and timeline purposes. Our normal practice here is to reduce the scope as much as we can, a process we consultants term as “Scope Optimisation” simply because it sounds grand. I mean it sounds better than “Reduce your scope” which generally is interpreted to “reduce your price”.

In general, there are six things that we have to compile before we truly initiate the PCI journey.

a) Location and Address of the PCI scope. This is simple enough. Usually your data center is in scope. Depending on whether you store, transmit or process card data in your other offices, those come in scope as well. A question here would be – what about HQ, where our administrators access the PCI systems in DC, via a VPN connection? Ah. The secret sauce of putting things out of scope in a remote location where there is no storage, transmission or processing (lets just shorten these to STP from here on) of card data but there is access from an admin systems – multi-factor authentication. As long as this is in place, while the admin system is in scope, the location itself is then put out of scope. So you can connect from Starbucks, your home, or Timbuktu, and you would not have these locations dragged into your precious scope.

b) Applications that STP CHD. Store, transmit or process card holder data. Many queries have been like – oh, do we need to use PA-DSS applications? Well, if you do use PA-DSS certified applications, it would be very useful. However, even if you do not, you can still access that application as part of your scope under Requirement 6. In fact, some applications may not even be able to be PA-DSS for many reasons, such as it not being part of the authorisation or settlement flow but still storing card data. A custom CRM for example would be one that cannot be PA-DSS but still in scope for card data application. OTC (off the counter) products that store card data are still in scope, however, they need to be assessed properly to determine if there are any security issues that may influence the confidentiality of card information.

c) Network Diagram – an updated network diagram is a must. And a network diagram needs to be detailed enough to be able to differentiate the PCI and non-PCI zones. The important thing we need to take note on the network diagram is the proper demarcation of PCI zones, so we know what are:

  1. Card data environment in scope (CDE-IN-SCOPE) – ZONE A
    1. Any system that store or process or transmit CHD
    2. For example, application server, Database server
  2. Non-Card data environment in scope (NON-CDE-INSCOPE) – ZONE B
    1. Any system that require to communicate with CHD
    2. For example, patch server, anti-virus server
  3. Out of Scope – ZONE C
    1. System not related and has no communication with CHD – but might communicate with NON CDE IN SCOPE.
    2. For example, CCTV server in your office environment

d) Asset List for PCI – the asset list is critical because this relates directly to the effort and remediation costs of your PCI program. There is a huge difference in doing pentest for 200 systems versus 20 systems. So in this case, we don’t care about your assets considered not in scope, we want to know the assets in CDE and in NON-CDE in scope (Zone A and B).

e) Public IP addresses – this is needed because of ASV scans required. ASV scans are security scans done by the ASV (Approved Scan Vendors) of PCI. You can’t do it yourself, you need to get an ASV to do this for you.

f) Data Flow Diagram – This shows the card data flow in your organisation. Basically every channel where credit card enters into your environment, stored and process and exits. This details the lifecycle of CHD in your organisation whether it ends up being stored in a database for seven years, or passed out to another service provider. It’s essential to understand this – and if you have multiple channels where card is being entered (e.g e-commerce, POS, MOTO, Call Centers, KIOSKS etc) you need to document each of these from start to end.

So there you have it. PCI scoping at your fingertips. Drop us an email at pcidss@pkfmalaysia.com and we can have a free session with your organisation on what could be your possible scope, which likely may not be just your printouts coming out of your printer!

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!

 

PCI-DSS: The Art of Getting By

April 6, 2018 / / 0 Comments

The Art of Getting By is a movie that wasn’t very good. I don’t recall much of it, except the title was appropriate for this article.

The general idea of PCI-DSS is that it’s easier to maintain the compliance than to first obtain it, and while there are nuggets of truth there, we would venture to turn that idea upside down: It’s much harder maintaining it that to obtain it. Maybe it’s like marriage, where after the wedding and honeymoon, the real work begins in ensuring you have 40-50 years left in the tank with your partner (depending on when you tie the knot of course, and in some cases, depending on how many kids you end up having. That’s added stress.). In some ways, it’s similar, and over 8 years of PCI experience had taught us that while we should always (again – ALWAYS) celebrate the success of first time compliance to PCI, we must not forget what lies ahead of us.

PCI Council realises this and in Appendix A3 of their PCI standard, lists out a few extra things for DESV (Designated Entities Supplemental Validation). It must be noted however, these are not automatically mandatory for PCI companies, but for companies designated by their card brands or acquirer based on risks and oftentimes, volume of transactions. If you are not required to go through DESV, don’t go searching for it.

DESV puts in a few extra components to the PCI standard. One of the requirements is to Implement a continuous PCI-DSS program in the organisation. What has been noted by the council is that while many companies do attain PCI-DSS, they treat the standard as an event they need to get by each year. This means companies, instead of practicing PCI in their daily work, seek to re-certify each year based on a series of checklist they need to do at that point in time. Which isn’t cool. But that’s how almost everyone approaches it. It’s like taking your semester exams in University. It’s not like in day to day living, we are thinking about the real value of x in a log2 equation or what are the prime numbers that are relevant to your life. We are just thinking about hanging out, cutting classes and kicking up dust. When the exams come, we mug, we eat ramen noodles for every single meal, we don’t go out, we don’t sleep and we generally try our darnest not to fail, and then the whole cycle of meaninglessness begins again. I don’t really recall much of my university days, as you can tell. And that’s how PCI is sometimes approached.

So how does one stay compliant, instead of just pass compliance?

Management Buy In

We hear this a lot from our management text books. Management Buy In. Unless we have a top down support and sponsor on compliance, PCI is going to be a drudgery faced every year. IT is going to be bombarded with all kinds of requests on top of their already busy day to day work. Most success comes if the business recognises the importance of PCI to their organisation. We have some rare instance where clients do PCI just “because they want to, and they want to look good”, but more often than not, those attempts fizzle out once they realise it’s a rabbit hole you can’t get out of. A cost benefit analysis is key here, and a business case needs to be built, because you are going to end up spending a lot in this compliance, and that spend should be backed up with sound revenue and business in the pipeline – directly generated because of your compliance.

Having a Compliance Team

You need a go-to guy, or a go-to group for this compliance. We have experience where PCI is dumped into an organisation and every week we are dealing with different people. We have one customer who named a project manager to lead the project and his appearance in our meetings is as rare as Yeti sightings. We sit in the meeting and we go, “Where’s so-and-so?”. Some wide eyed junior IT guy goes, “Oh he’s busy with another project, and I am asked to lead”. Anything we discuss, he just goes, “OK, I need to check with so-and-so and get back to you.” Without decision makers in the team, we end up going around in circles and before you know it, 6 months have passed and we are still on the same agenda. It’s like going 3 levels deep in an Inception dream. Get a team. You don’t need to bring in 20 people in the meeting where 18 people sit away from the table, typing furiously at their laptops as if they are writing the next War and Peace novel. 3 or 4 key guys: Person in charge, network and server team representatives, developer rep and if you have SOC/security team rep. Everyone should either be an influencer or a decision maker, and we are good to go.

Business As Usual

We call it BAU. Many have suggested PCI is asking ridiculous requirements which are too difficult to meet. In reality, PCI is basically asking for baselines. The very least organisations should be doing to secure themselves. Security needs to be practiced, and not just implemented as a checklist over a short period of time. For instance, the requirement for daily log monitoring. This is not something you can conjure up when the auditor comes and audit. If you are not practicing it, you are not practicing it. Or simple things like CCTV monitoring. We faced a client doing recertification and on a pre-audit check, we found their CCTV had not be recording for 8 months due to maintenance. I asked why was this not reported or checked, and they sheepishly told me they had no clue and they had never bothered to even check since they passed their cert. PCI requires a fair bit from organisations, for example:

Daily Monitoring of logs, and access to secure area, weekly checks on FIM logs

Monthly checks on critical patches

Quarterly – Wireless Scans, ASV, Internal Scans

Half Yearly – Firewall review, user deactivation

Annual – Pentest, application testing, Risk assessment, training, Inventory checks and review, policy review, service provider review, Incident response, segment checks etc

Those are just part of the listing. So unless you plan to have sleepless nights during the audit period, it’s best to get these done as part of your day to day. We need to note that in most cases, these should be practiced in any case, regardless of PCI or not!

Yes, a lot of these are easier said than done. We are aware teams are being pulled sixteen different directions and PCI is just one of it. It falls back to how critical this compliance is. To many, it’s required to continue their business as it is a contractual obligation. So it’s not just about getting by, although in some cases that might work – but for PCI, we would recommend to embed these practices as much as possible into your organisation, so that when audit season comes, you don’t end up overeating your Ramen noodles.

Get in touch with us through pcidss@pkfmalaysia.com for any enquiry on PCI-DSS!

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 ↑