Category: IT Audit (Page 13 of 13)

The Essentials of a Service Level Agreement

In PKF Avant Edge, one of the things we’ve been asked to do is to provide advisory and implementation on policies and procedures. We find a lot of companies have sound policies governing internal processes, but not so sound policies governing third-party providers. Some have not even heard of a Service Level Agreement (SLA) before, and when asked when would the vendor respond to their IT issues, they blissfully responded, “Maybe tomorrow. Sometimes next week.”

In many cases, the promise of a cheap service provider, whether supporting your network, your server or devices or simply IT infra; is enough for the company. As long as they pay RM1000 less a month, that’s all that matters. Is it? What if you get crap service? What if the provider is unable to support certain things? What if there are variation orders for additional tasks not provided for?

This is where proper third party governance comes in. It’s invariably a critical process we look at in all our IT audit exercises. No use strengthening internally when your dependence on external parties are not properly structured!

What is a Service Level Agreement?

A service level agreement is a contract between a service provider and a customer that specifies what the services are being provided by the service provider. The services can be measured, justified and compared to those who are providing the same services.

 

The benefits of SLA:

  1. A proper SLA helps to strengthen communication, so that the parties come to better understand each other’s need, priorities and concerns.
  2. The SLA process facilitates the identification and discussion of expectations. Therefore, the two parties will achieve shared expectations about services and service delivery.
  3. With shared understanding about needs and priorities .An SLA and the communication process involved helps to minimize the number and intensity of conflicts.
  4. SLA provides mechanism for periodic review and modifications to services, expectations and responsibilities due to changing circumstances.
  5. With the presence of an agreement, SLA provides a consistent, on-going and mutually agreed to basis for assessing the service effectiveness.

The key components to SLA:

  1. List the exact services being provided so that customer will not expect more than the expected services listed in the SLA.
  2. Let the customer know what they should expect from you and what you expect from them.
  3. SLA give customers a timetable to let them know how long it will take the service provider to get back with them via phone call, email or whatever agreed upon method is.
  4. Let the customer know what is the procedure for any disagreement and how exactly it is handled will gives the customer peace of mind.
  5. The SLA let you know when you’re expected to pay and if you don’t pay by that time, what the repercussions will be.

Popular metrics used in Customer service:

  1. Turn Around Time: The time it takes you to complete any given task.
  2. Time Service Factor: A percentage of calls answered within a defined timeframe.
  3. Average Speed to Answer: This is self-explanatory, the amount of time it takes to have a call answered by your customer service agents.
  4. Abandonment Rate: Percentage of calls abandoned while they are waiting to be answered.

Why do SLAs fail?

  1. Service providers want to create an SLA to suppress customer complaints. Conversely, customers want to use an SLA to blow the service provider whenever service slips.
  2. The process of communicating and building the foundation for a win-win relationship is essential to the success of SLA. It is much more than just filling in the SLA template. If the relationship is lacking, even the best-written document will be worthless.
  3. Both parties must be involved in the formulation of an SLA. If one party attempts to control the process, member of the other party may resist its provision even if they might otherwise support them.
  4. A common misconception is that once the SLA document is complete, the job is done. As a result, an SLA that is not managed fails upon implementation.

So please, if you haven’t done so, ask yourself: “Did we formalise our relationship with the service provider? Has an NDA been singed? Are proper SLAs measurements in place?”. Gone are the days of a handshake agreement. We now need proper documentary proof to govern how we run our businesses.

 

 

 

 

 

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”?

 

 

 

So much for confidentiality

Everyone has a similar story.

You print out something, then walk over to to your printer located 20 meters away, shared by the four departments on your floor. Instead of your print out, you have a whole stack of other people’s printout and the paper has run out. You look at the task, groan as you see another 120 pages pending. And the one who printed out that stack is nowhere to be found.

Looking further, you see, well, the stack had some pretty interesting information. Apparently it’s the entire year’s worth of financial information and also a few pages detailing employee’s pay and salary. Now you know how much your annoying colleague who just bought an Audi A8 earns, and you are really, really peeved, because you know he doesn’t do anything but play golf and suck up to upper management.

Where is the problem here?

Whatever confidentiality classification a company has put in place is out the window, when an irresponsible employee just prints out 150 pages and goes out for lunch and says, “I’ll grab it on the way back.”

An interesting article here talks about how some secret files from UK has gone missing or destroyed. According to the article: “The Foreign and Commonwealth Office is unable to confirm whether 170 boxes of classified documents which were returned to the UK at the end of the colonial era have been destroyed.”

Oops.

The article continues on detailing some of the acts that were done during the british rule in Kenya, where prison warders apparently clubbed prisoners to death and blamed it on “Drinking too much water.”

As in, seriously. I’m not sure if that’s British humor involved in the drinking too much water part, but it’s pretty humiliating for the FCO any way you look at it.

In an application audit we did, the team found pretty good controls overall, but flagged an issue: Invoices and documents containing confidential information on partners and payment details were left in a box in a common area before moving to a more secured location. The common area was where many people on that floor walked by. Now, our client reason, nobody would be looking into the box without any business with it. Also, they were all employees of the same company. And finally, it was only a temporary storage, and each day, the stack will be moved to the supervisor’s cubicle for filing.

We insisted on flagging it. The assumption of above’s argument was that all employees can be trusted. And along with that assumption comes: all employees are nice people who does what is best for the company.

Um. That’s very idealistic, like me winning American Idol and going on to become a global superstar. And chilling with Bono at a cafe. Of course we didn’t put that in our audit report.

But here’s the thing, if you’re going to spend millions on technical controls, but not look into the process and people controls, we’re defeating the purpose of holistic security. The weakest link is the people, either through deliberate malicious acts, or just plain unawareness, the company takes the brunt of the oversight. Security should be approached in that holistic fashion, and that’s why IT Audits are still relevant in a world where security companies have invented automated “IT Audits” by installing their software and they would probe for software weaknesses and “Outdated patches”. That only tells part of the story. The other part is breaking down the critical processes and human interaction between systems and technology. Any IT Audit that does not take time to understand the business process of a company isn’t complete.

So back to the FCO, we don’t know what happened. Maybe somebody printed out the whole bunch of secret stuff and went for lunch and somebody picked up the documents and went, “Jeez, this is going to make the honchos in UK look like a bunch of clowns”. And also, what do you know, reveal some seriously critical military secrets. Somewhere along the way, somebody dropped the ball. It’s a human issue. Or it’s a process issue. Unfortunately, when we hear people doing “IT Security Audits” they take the “IT” word too literally and the “Security” word too frivolously. That in itself is worth another article.

So for now, please grab everything you print out before you head out to lunch!

The Single Point of Failure

As technology becomes more and more advanced, we’re seeing an amazing progress in the security field. Companies spend millions to keep the bad guys out. We have IPS/IDS, NACs, AVs, FWs, AAA, TACACS, ADS, IAM, SIEM and more acronyms than a typical teenager’s vocabulary.  Security budgets consistently spans 10 – 15% of organisation budgets, and according to the greatest oracle of all, Gartner:

“While the global economic slowdown has been putting pressure on IT budgets, security is expected to remain a priority through 2016, according to Gartner, Inc. Worldwide spending on security is expected to rise to $60 billion in 2012, up 8.4 percent from $55 billion in 2011. Gartner expects this trajectory to continue, reaching $86 billion in 2016.”

So this year, we’re seeing an IT security spending of the GDP of Cuba. Yup, Cuba. Where Havana cigars come from and Che Guevara became famous. It sounds like a lot of money. And it will get higher. As long as more automation is done. As long as more technology is needed. As long as more day-to-day banking is needed. As long as human beings are lazier and want more things faster. Information Technology will continue to grow, and along with it, all the wonderfully, naughty activities that invariably accompany such growth.

While millions are spent on equipments, many of us neglect one of the most basic problem of all.

Passwords don’t work.

That’s because humans are invariably lazy. Or we would rather remember the phone number of that girl we met at the bar, or the pizza take out than to bother remembering our 12 letter, alpha numeric, lower case, upper case, special character password that must not resemble an english word or name, and must not be the same as the last 12 passwords you have, and recycled every month. And yeah, also can’t be your name, your family name, your dog’s name or the nickname you named your car. Or your bike. Or your computer, for us geeks.

It’s a broken feature. This article is both hilarious and scary. Like a korean horror movie.

Since biometric tech like fingerprint and face scanning is too expensive at the moment, passwords are still the defacto security problem many of us face. You can’t impose too complicated passwords on your users or your IT service desk will be flooded with “I forgot my password” tickets. Or you will have to constantly implement a “Reset you password” feature every day. But having no password policies is also asking for it. Users will tend to use password as password, which if you think about it, is absolutely genius if no one knows about it. It’s like doing the most stupidly obvious thing that your enemy would not believe that you’d be stupid enough to do it. Except now, it’s a known and acceptable stupidity, like lemmings falling off a cliff.

Password123, p@ssw0rd (or any other variants of that), password1, password2012 etc have all the same funky, useless theme: we are lazy creatures. The list has some interesting ones, like abc123 (who has never used that before?) and interestingly, Jesus, which is new. I mean, is that due to lots of IT users are christians, or that would be the first word that comes out of people’s lips when they think “Now what on earth is my password already???!”

Since passwords will never leave us for the near future, the best way to use a password is  simple, specific, and only you know about it. For instance, if you met your wife in Cicero’s on June 1986, your password could be c1cer0s1986_J. Or something. Craft out something that when you see that word, you can immediately associate it with a memory you have. Or if you paraglided down Mount Mutombo in Venuzuela with a guy called Hokey who then proceeded to almost kill you because you are a secret agent: Mut0mb0V3n_Hok3y_Di3! I don’t know. You get the idea.

So put away the normal passwords, and more importantly don’t ever, ever use yellow stick it notes on your cubicle, monitor, desk, pedestal, under your keyboard or under your chair. Please.

Newer posts »

© 2024 PKF AvantEdge

Up ↑