Tag: it audit

Hardening Checklist

Requirement 2.2 has been often deliberated by customers undergoing PCI-DSS. To recap, the requirement states:

Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Sources of industry-accepted system hardening standards may include, but are not limited to:
• Center for Internet Security (CIS)
• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST).

Requirement 2.2

So often, customers go ahead and download the CIS hardening documents at https://www.cisecurity.org/cis-benchmarks/ and copy lock stock and barrel into their policies and send it in. Now all this may be well and good, but now you have around 1,200 page tome with guidelines like 14 character alphanumeric password, as opposed to what PCI requires (7 Alphanumeric). This is where our customers get stuck, and some even send in a 1000 page hardening document to us to review, only for us to find that they have not implemented even 1% of what is noted in their hardening document.

After that, the hardening documents get re-jigged again until it meets a reasonable, practical standard that is implementable, usually in the form of a checklist. For a very quick hardening checklist, this is the initial one we often end up using, just to get our clients up to baseline speed, whether it’s PCI or not:

Hardening ItemServersNetwork DevicesDatabases
Assign individual server for each critical role (App, Web, DB, AD, AV, Patching etc)YNAY
Disable/Rename/Remove default user accountsYYY
Assign role based access to usersYYY
Disable insesure or unnecessary servicesYYNA
Use Secure Versions of Remote Access Services (SSH, RDP over SSL)YYY
Install well known Anti Virus with latest signaturesYNANA
Install latest OS / Firmware / Software security patchesYYY
Disable inactive users automatically after 90 daysYYY
Ensure Following Password Policies –
1. Use Complex Password with 7 characters or more
2. Remember minimum last 4 Passwords
3. Require passsword change within 90 days
4. Require password change upon password reset and first logon
YYY
Ensure following account policies –
1. Account lockout threshold – Max 6 attempts
2. Account lockdout duration – 30 mins or until admin unlocks
3. Idle Session Timeout – 15 Mins or less
YYY
Ensure passwords are stored securely with encryptionYYY
Enable Audit logging to Capture at minimum following events –
1. Successful Login
2. Failed Login
3. Administrative Actions
4. User Creation
5. User Deletion
6. User Updates
7. Escalation of Privileges
8. Access to Audit Trails
9. Initialization or stopping auditing
YYY
Configure NTP and time syncronizationYYY
Implement File Integrity Monitoring`YYY

Now obviously this doesn’t cover all the requirements of PCI (testing, scans, retention etc) but this should give us a fair idea of how ready our systems are for an audit or assessment.

If you have any queries on PCI or ISMS or any other security related standard, drop us a message at avantedge@pkfmalaysia.com.

PCI-DSS: The Art of Getting By

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!

Strange Tales from Auditing IT

“Hi, I am your IT auditor,” says the young lady before me. She is well dressed with unassuming colors, pencilskirt shaping her just enough without looking too informal. Beside her is an equally well dressed man. Or boy, more precisely. With those fashionably tall hair, waved as if he had just came out of a nearby hair salon, with those slightly tight pants, ending with shiny shoes with tips sharp enough to stab someone.

“Just show us where is our place, and your IT group, and we’ll be on our way!” she chirps merrily. After introducing her to my bleary-eyed IT manager, I went back into my austere chambers, decorated minimally, with plenty of space for the stacks of ring-files that documented my entire career as an Head Internal Auditor of XXYY company. And I waited. Surely one of these well dressed, articulate, young IT auditors will be asking me for a sit-down session on some of the perceived challenges of IT aligning with our business, and how we can improve. Surely, once she’s done mapping out the technical areas with my IT manager, she would surely come and talk to me about how the IT audit will be done, and how as the Head of Internal Audit, I should be aware of the findings and recommendations, since I was the one who hired her firm in the first place.

One day passed. No sighting. Maybe IT was really complicated after all, although the company’s usage of IT would have been pretty minimal, seeing that we only used e-mail mainly. We only had 3 guys in the IT shop running everything.

Day two, day three passed and finally, I decided to go down to IT and see what the heck was going on. My IT manager was there, as usual, obsessively browser surfing 10 different windows on his large monitor.

“Where are the auditors?”

“They’ve already packed up and gone yesterday.”

Flabbergasted, I went back to my room. So 3 days was all it took to do an IT audit? Who did they interview? Who did they talk to in order to understand the business needs, risks and processes? How did they communicate with the business without me knowing? What were we measuring? How?

They must have bypassed me and went straight to the business owners. That must be it.

Tapping the phone in front of me, I got hold of several of the stakeholders of the IT applications running in our company. All of them denied seeing anyone in a pencilskirt accompanied by a wavy hair boy. Some of these stakeholders would definitely remember anyone in a pencilskirt, so I guess they were telling the truth.

So the IT auditors were almost like phantoms. Ghosting in, and in 3 days, ghosting out again, never talking to any of the key stakeholders. How on earth did they do their audits then?

The above is a fictionalised account of an experience that was shared to me, on IT auditing. Although somewhat humorous, I still find it alarming that IT audits are still being conducted in this way: go in, talk to IT, sit them down with a checklist and get them to implement the checklist. There’s no context of the audit, no risk analysis, no understanding of the business flows, or how it interacts with IT. No comprehension of critical processes, or the role that IT plays in the broader aspects of business. They carry with them a pen and paper and a checklist, and goes in to the poor IT manager’s room and shoots him when he answers, “Umm, what’s a BCP?”, and shaking their collective IT auditor heads until the manager feels like a donkey in front of this pair, young enough to be his kids.

Checklists and irrelevant benchmarking.

IT auditors who do not take time to understand the context of their audits are wasting their time. Worse, they are disrespecting the customer. If a client has 3 people in his IT and generally use IT only for automation of processes, without too much dependence on it, why do you insist to flag a red flag of non-compliance to COBIT by saying they need to come up with an IT Strategic Plan? Or have a IT Steering committee? And what on earth is a non-compliance to COBIT? COBIT isn’t even a compliance standard!

We’ve seen our share of these “quack auditors” we call them, in our landscape. Of course, for every quack, we also find very good, self-respecting ones. But the quacks are the ones that gives IT audit a bad name. Suddenly people want to know if we do COBIT compliance. I even saw a proposal as thick as the Bible, expostulating to the client that they need to have all 318 control objectives in place, and the audit will cover ALL control objectives in a unified regulatory software. Which is a glorified checklist on excel.

It’s tough, and sometimes we compare our adventures in IT audits to wild wild western movies, where law and order was non-existent. Until we start educating and creating awareness in our clients on how to apply COBIT as a framework or as a compliance to a standard, and not a standard in itself, we’ll be seeing these quack auditors all over the place. It’s like someone exalting the miraculous cure of radioactive medicines in the 1920s, only for the patient to die from these quackery.

Entering into 2013, we would love to see some regulation on how IT audits should be done. In fact, as I always say, remove the “Technology” and just call it Information Security Audit. Now, who would you talk to about “information”, not “Technology”?

 

 

 

PKF AvantEdge First Post

It’s always a little difficult to decide on how the first post should be created. Do we immediately go into what we do as a company? Do we state our vision, mission and all that corporate talk? Do we jump into what our industry is currently facing, at this moment, I am looking at the theft of secured information in NASA. How on earth does someone in NASA loses his laptop and not have whole disk encryption?

I think there will be plenty of time for that later.

Instead this first post simply states the philosophy of PKF Avant Edge. Not as an IT consulting company. Not as a professional service group. Not as a project management company. But simply, as an entity.

I have had more than 10 years of experience in the corporate world before I decided to set up the company. 10 years in 3 companies: Siemens, DHL Asia-Pacific Information Services and BlueCoat Systems. 2 German companies. 1 American. Along the way, I’ve met with people who had shaped me somewhat into what I am, people who had imparted their own brand of management, philosophies, methods, giving me waysigns to follow, and showing me characteristics I should avoid.

When PKF AvantEdge started, it had a simple goal. Make positive history. It doesn’t matter how. I wasn’t interested to be recycled into the myriads of System Integration businesses out there. We’ve dealt with principals, resellers all our lives, and we were following a well beaten path. This time, we needed to create our own history. Become a company that people want to be a part of. Create a culture of creativity. Create an environment of constant change. Find the patterns of tomorrow and pursue it today.

The last part proves the toughest. Wayne Gretzky, commonly known as the greatest ice-hockey player in history, says, “I skate to where the puck is going to be, not where it has been.” Through 2 and half years, that quote epitomizes our company. We envisioned a technology landscape that is so integrated to the major portions of the business that regulatory compliance is unavoidable. We saw the advent of hacktivist groups like Anonymous when we started, and pitched for companies to strengthen their technical resolves. We see a movement to information plundering using social networks and medias, trawling literally across the vast ocean of data to steal identity  and information assets.

The future of our business landscape will be defined by corporate earthquakes like Knight Capital, which saw a $440 million trading loss caused by a software glitch, and their shares free-falling 80% in two days. Or Adobe losing 150,000 user accounts based on SQL injection. Or take-your-pick ERP implementation disasters that run into the millions with no results at the end.

While I’m not saying that we are market leaders in tech consulting currently (by any stretch of imagination), I believe this is where the puck is going. Regulatory controls, more stringent requirements, certified and accredited qualifications of practitioners. It will look more like the banking landscape in a few years time.

Now, we can move on and discuss about how those geniuses at NASA can fail to encrypt their laptops….

© 2021 PKF AvantEdge

Up ↑