PKF AvantEdge

Category: Risk Management (Page 5 of 5)

The Problem According to TRIZ

January 15, 2013 / / 0 Comments

As a former head of IT security running close to 350 security devices worldwide for DHL, I think I have a pretty good grasp of problem solving skills. We used to deal with tens of incident tickets coming in. Tens of tickets might lead to fewer problems, but this doesn’t mean it gets easier. Problems might end up being just symptoms of a bigger issue. The list goes on. Having passed the ITIL cert, I was curious on how we could better manage problem resolution. Incident resolution I get it. Just get the service up and running either through a workaround or resolving the underlying problem. The former is what I now know as the ‘sweet spot’, distinct compromises that has an improvement and a worsening factor. The latter is problem management, which I haven’t done too well. Try having half of China yelling into your ear to get those F5 BigIP load balancers to work properly so that delivery planes are cleared to take off, or face a multi million of USD loss per hour.

I would venture to say all incidents should be dealt with to get the service up, but should also lead to a more methodical problem management, to solve the underlying issue so that it does NOT happen again.

Over the weekend, I attended an intriguing course by a reknowned practitioner of TRIZ, who worked with Intel.TRIZ is a russian acronym, and stands for Theory of Inventive Problem Solving. I hear some of you going, “Wait, that’s TIPS.” OK, TRIZ stands for teoriya resheniya izobretatelskikh zadatch, which in Russian, means “Don’t-try-to-pronounce-it-and-destroy-our-mother-tongue” to most of us. In fact the real writing is in russian script, which, to decipher it, would probably take me about the same time to be fluent in Middle-Earth Elvish.

But that aside, TRIZ is actually a very interesting way to look at problem resolution. It’s a concept supported by its own tools to look into a problem in an inventive manner. Meaning, we’re here to resolve contradictions. For instance, to solve my computer’s performance, I increase the CPU, but with that, I need to improve my cooling fan. That’s a contradiction. When something gets better, something else gets worse. Immediately, you’d think, why not spend extra money and buy a bigger cooling fan? Using TRIZ however, it does away with experiential learning and simply breaks down the function, understand the cause and effect, and trim away areas that are not relevant, until it comes up with a specific “Inventive Principle” to address the problem. In this case, it might just be putting the computer inside your data center with special external cooling, as opposed to under your desk, stacked with moldy papers.

One of the idea of TRIZ is to break down the problem into functions and identify worsening and improving parameters based on 39 Systems Parameters. Then, using the contradiction matrix, identify among the 40 Inventive Principles how to resolve these. The philosophy of the 40 principles is taken from  thousands of patents, and how they address our needs. Apparently this is a conclusive list, and hasn’t changed since the 60s. That’s a pretty steady list.

After intensive training, we sat for the TRIZ certification exams and passed. So, PKF becomes the first management advisory firm with TRIZ certified people in it. A lot of it makes sense to me, as we always used to approach a problem in either a novel way or use our previous experience with the problem to address it. Both might or might not work, but with TRIZ, at least the alternatives are better mapped out.

Read it up in this WIKI, it’s quite an interesting concept; the world according to TRIZ!

 

CyberInsurance: The New Frontier

December 18, 2012 / / 0 Comments

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.

 

PCI-DSS, ISO27001, COBIT and a Partridge in a Pear Tree

December 17, 2012 / / 0 Comments

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.

The Trouble With Convenience

November 18, 2012 / / 0 Comments

It’s probably not the best time to be working in a bank.

Especially if you’re in Europe of US.

Number 1, the global layoffs occuring, with HSBC announcing 30,000 job cuts in 2013. 30,000. That’s roughly 10% of its workforce. This is mainly due to operations streamlining and of course, cost cutting. Which actually doesn’t mean bad news to our region, since we’re considered as the backend of the world, and possibly, one analysts’ pay in US is equivalent to our CIO’s take home income. That’s just a wild, ignorant and completely ungrounded guess.

Number 2, more than ever, banks will be targeted by hackers, crackers and everything in between. Of course, with internet banking on the rise, and the fact that passwords are absolutely worthless these days, it only takes a very focused and somewhat skilled individual to exploit money away from other people. Even if they don’t they can still cause mischief by laying down DOS (Denial of Service) attacks on the target. We can’t really avoid it, using internet banking. That’s the trouble with convenience. It gets exploited.

Again, HSBC, which seem to have fallen from one of the world’s best and most beloved bank to one that is constantly being targeted by various groups. In October, the first wave of DOS hit them, and took out their UK site and many others. On November 4th, the similar attacks took out the UK site again, and reported, “As of yet, HSBC doesn’t know what’s causing the failure, though the spokesperson said it was likely to be something affecting the “servers or mainframe”.”

Hacktivists have taken credit for HSBC downtime, but whoever it was, it was certainly disruptive to the business.

Could the bank have done anything to avoid this?

They probably could have made it harder. But DDOS is one of the most annoying thing ever invented for an operational guy. And I would know it. I ran the global DHL network and DDOS was on our menu. Everyday.

One of the ways we did for our global website was running it on Akamai service, which alleviated the risk somewhat. But then, even Akamai gets hit so I suppose no one is safe. Until someone claims he/she has full proof solution, I guess it’s something we all have to live by.

Just make sure you have a backup and IT continuity plan ready.

Newer posts »

© 2024 PKF AvantEdge

— Up ↑