To all our readers and clients celebrating Chinese New Year,
May the good health, good luck and great success be with you always. For those who are travelling, wishing you a safe and peaceful journey!
Author: pkfavantedge (Page 37 of 37)
With the rapid advancement in information technology, businesses are moving to an intensive IT-integrated model. By utilizing the features of information technology, businesses are able to reach out to more audiences, regardless of geographical aspects and language barriers. This provides an advantage to business; higher audience in a relative lower costs. However, the utilization of information technology is a double-edge blade, as confidential information are stored as data in servers available in the internet, as compared to printed hard copies of documents kept and locked in cabinets.
To ensure continuous availability of information, the network the server resides is connected to an untrusted network, namely the Internet. In order to protect unauthorised access to the information, security measures are needed to be implemented. In this article, we will discuss about the firewalls and intrusion detection systems.
Difference between Firewall and Intrusion detection system
A firewall is a device or group of devices that enforces an access control policy among networks.” Its main function is to control incoming and outgoing traffic, between two networks by allowing and denying such traffic depending on pre-determined rule sets. Therefore, a firewall is a preventive control acting as keys and locks between the networks, as shown in figure 1 below:
An Intrusion detection system (IDS) on another hand, is a device or application that monitors network activities and attempts to detect suspicious activities going through the network. Consider IDS as a burglar alarm for your office; when they enter your office (i.e. unauthorised access), the alarm will alert you. Therefore, IDS is a detective control; its main function is to warn you of suspicious activity taking place ? not prevent them (Refer to figure 2):
Reason for IDS
A firewall is a crucial component of securing your network. The predefined rule set within the firewall provides protection that any traffic going through the closed ports are denied but also allows some of these through the network as well. However this means that the access allowed is just let through, and firewalls have no clever way of telling whether that traffic is legit and normal. This is where IDS comes into play.
Placed between the firewall and the system being secured, a network based IDS can provide an extra layer of protection to that system. For example, monitoring access from the internet to the sensitive data ports of the secured system can determine whether the firewall has perhaps been compromised, or whether an unknown mechanism has been used to bypass the security mechanisms of the firewall to access the network being protected.
Let’s take a look at an example by referring firewalls to locked doors (key and locks) and IDS to alarm systems (as mentioned above). Let’s say that you have lots of confidential documents stored in a filing room within your office: The locked doors will stop unauthorized individuals from entering the filing room. By themselves, they do nothing to alert you of an intrusion, but they deter unauthorized access. The alarm system will alert you in case an intruder tries to get into the filing room. By itself, it does nothing to prevent an intrusion, but it alerts you to the potential of an intrusion. As you can see, both security mechanisms complement each other, providing better overall security towards the access of such confidential documents.
It should be noted that IDS should not be employed as a single security mechanism. By using a layered approach, or defence in depth, a network should have multiple layers of security, each with its own function, to complement the overall security strategy of the organization.
Conclusion
Before implementing security controls within the organisation, it is crucial to conduct a risk analysis based on the confidentiality, integrity and availability of the data. As there are almost no servers that are immune to penetration/intrusion, it is recommended that the security mechanism implemented are capable of minimizing the risk.
In the next article, we will talk about Intrusion Prevention System and the reason for having one within an organisation.
I recall back in 2009, I gave a presentation on the importance of risk management in IT, and how having strong technical controls such as proxy gateways will help alleviate network security risks. At that time, I was the head of APAC Services for BlueCoat Systems, a Silicon Valley company specialising in proxy and WAN optimisation technologies.
Someone then asked me, “Why not we just transfer all our cyber risks to someone else?”
I was pitching a sale, but I was a terrible salesman. So we engaged in an interesting discussion on the case for “cyberinsurance”. Back in 2009, my argument was pretty simple: there were limited ways to measure cyber risks. Unlike life insurance or health, where you had historical records, I can safely say, a majority of cyber breach will go either unreported or unknown. Would anyone insure a company when they did not know if that company was currently hacked, has been hacked, or has been compromised without knowing? Or how would they cover if the company purposely gets hackers to hack their system to claim their insurance? There were too many variables.
Fast forward 4 years and cyberinsurance is still met with a mixture of disdain, disbelief and skepticism. But the numbers show that in the past 4 years, the alarming increase of cyber threat incidents gives the thought of cyberinsurance new legs to run on.
In our Twitter, we list out security issues in the wild wild Cyberspace. Over the years, we’ve seen behemoths like Facebook, Google, NASA, BoA, Sony, Samsung, Amazon, Yahoo, Microsoft…you know what, just throw in Lockheed, RSA, the government of the United States and every big company you can think of…all have their own variance of security incidents, either dealing with data confidentiality breach, integrity compromise or availability issues. According to the article on Wall Street Journal, most of the data breach occurs at SMBs.Those are reported cases. God knows how many dormant trojans, worms and hidden malware were there, systematically sucking information from insecure devices in small businesses or gearing up for a massive zombie DDOS attack on large companies on New Year’s Eve.
Perhaps it’s time to rethink the need for Cyberinsurance.
In PKF Avant Edge, we’ve been engaged on a number of data forensics projects. All these happened after a data breach or suspected fraud in the company. One of the questions we get asked is: “How much does it cost?”
Getting IT forensics experts is not cheap, although we’re quite certain we offer the lowest and most cost effective, qualified consultation in the market. But we’re still more expensive than the Low Yat guy that runs a freeware data recovery tool. Low Yat is this huge computer selling mall in Kuala Lumpur. The problem with these attempts (and boy, have we seen these so many times), is that it’s a hack job that doesn’t hold up in court. Anti-forensics dictate that qualifications, tools and methodologies must be in place. Tell that to Mr Low Yat.
But instead of bearing the cost of after-breach investigation, why not have cyberinsurance to cover instead?
Of course, the golden question here is, what should cyberinsurance at least cover? Followed by equally important and mind stumping questions like: How much premium to charge? What should NOT be covered?
One way to demystify the technical jargons from IT is to look at cyberinsurance as…an Insurance. Before approving a policy, what does a policy cover? Based on that individual, how much premium to charge?
Cyberinsurance should at least cover the following:
1) Data confidentiality and Integrity Risks – regulatory fines such as PDPA, PCI-DSS; forensic costs and investigation costs; PR costs and summonses, consequent security audits; third party claims and expenses. It’s pretty hard to cover the actual data loss since quantifying it to a dollar value is so subjective, but there could be a possibility, for instance the intellectual property of Apple was quantified to a billion. Ask Samsung.
2) Availability Risks – loss of business based on website downtime; DDOS incidents and virus attacks; incident response costs; IT specialists cost for post-attack cleanup and monitoring; PR costs. This should be focused on companies that depend a lot on their websites for their business. If hacked, what is the loss to the business?
Cyberinsurance is still at a very, very young stage. However, we’re going to see an exponential progress in technology in the next 3 years, faster than the last 10 years. Big Data, Virtualisation, Cloud technology. IT will be so soaked into every business that companies will have no choice but to leverage on IT to not just differentiate, but to basically survive. And with IT adoption comes the risks of running IT. Like in nature, the conditions of the environment are just about right for cyberinsurance to become the next step in the evolution of the insurance industry.
We just secured another PCI-DSS deal today, and once the customary celebration has died down, we will set aside time to start planning for the project. For this project, PKF works with our QSA (Qualified Security Assessor) vendor, Control Case, to ensure that our clients get the best consultation and services possible, and to almost guarantee a certification in PCI-DSS. I say almost guarantee, because there are no such thing as 100% in this world. For instance, what if a meteor crashes on earth just as the PCI-DSS audit was about to start? Sure, we’ll all go the way of the dinosaurs, but was our client certified? No!
Anyway, jokes aside, we’re gearing up for the new year, with PCI-DSS, some ISO27001 and our normal COBIT assurances in the pipeline. The reason why we focus so much on these 3 standards and framework (COBIT is NOT a standard!) is because they are inter-related. ISACA and other groups have mapped all three to each other in a sort of matrix fashion, so that sitting down with a PCI-DSS guy and talking about the 12 requirements, you inherently can map COBIT controls on those 12 requirements, and hey, presto, to the 11 domains of ISO27001. PCI-DSS can be mapped against ISO27001 as well, especially to the holy Annex A controls of the ISO standard. The fact is, anyone that has ISO 27001 experience will be interlaced with PCI-DSS and COBIT as well. They are all siblings of the same mother, IT governance and audit.
Of the 3, both PCI-DSS and COBIT has taken major steps forward. PCI-DSS 2.0 came out 2 years back and added in virtualisation and a lot more clarifications on testing procedures. The big step forward was that now risk assessment documentation must be verified against accepted risk management methodology. Before this, there wasn’t such a need. In doing so, PCI-DSS is moving closer to his bigger brother, ISO27001, which is risk-based.
COBIT has always been risk based. Anyone that comes at you with a COBIT checklist should be questioned. We’re not saying checklist is wrong, but there must be a context of that checklist. We see a lot of “checklist based on industry benchmarks.” That’s one way. But each business is different. Not every IT division needs a IT strategic roadmap with a 5 year plan on IT investments. I know one of my client whose IT guy is basically the guy from Low Yat, doesn’t. That client needs more controls on information leakage and policies governing that Low Yat guy. Fix what’s priority. Fix what is highest risk. And in order to do that, you need to know, interact, interview with the client.
COBIT 5 takes this literally. For too many years, practitioners has been throwing COBIT controls like fireworks on Chinese New Year Eve. Comply to this, else we will give you a big fat zero! We’ve been using COBIT 4.1 for a long time now, and it still remains an ‘auditor’s framework’. With COBIT 5, we move up the ranks to IT governance. It’s a different way to audit. Here we look at the causal relationships of IT and business. The controls tie to the governance of IT within the context of the organisation, hence putting practitioners with risk experience to the forefront. Unlike the haphazard way of trying to tie RISK IT, VAL IT and COBIT together, COBIT 5 hopes to bring in a more uniform approach to IT auditing, one that will hopefully transpose the audit from the realm of the IT techies to the board.
With COBIT 5, the checklist wielding junior internal auditor whose knowledge of IT consist of facebook and farmville will, hopefully, go the way of the dinosaur, and be replaced by practitioners who has real world experience, management insights and the technical-business acumen to bridge technology into corporate relevance.
“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”?
© 2025 PKF AvantEdge
— Up ↑