Category: Security Good Practices

I’ve only been blogging a month, and I have already repeated the following statement a dozen times in a variety of ways. It’s not that I’ve run out of things to say, or even ways to say it – if you know me, you know that’s not possible – it’s just that it’s THAT important;

Don’t buy ANYTHING until you’ve performed a Risk Assessment, and you know exactly WHY you’re buying it.

The only exception to that rule is buying a risk assessment obviously.

In Core Concept 1: Risk Assessment / Business Impact Analysis, and Insecurity Through Technology, I have tried to stress that technology, for technology’s sake, can actually reduce your ability to perform both security monitoring, and incident response. Security needs to be simple to be effective and sustainable.

Your risk assessment will detail exactly what your security posture should be in terms of mitigation / transfer / acceptance of risk, and operational resilience. The next step therefore is to see just how close you are to achieving those goals with your current controls. This will include policies, standards and procedures, data flow and storage (business processes), applications, infrastructure and so on. This is not just an IT gap analysis, this is a security and business continuity gap analysis.

Like the risk assessment, I’m not going to bore you with a list of the things that may need attention, it’s up to you to ensure you are conducting the gap analysis with the right resources to paint the most accurate picture possible. If you can do this with just internal resources, great, but consider bringing in external consulting help to ensure both objectivity, and deeper coverage of the security relevant skills and experience.

OK, let’s assume you now have your gap analysis, which includes a list of recommendations. These will most likely be far broader and/or deeper than you will ever have the ability or budget to fix completely. That’s OK, there’s no such thing as 100% secure, and you should not be striving for perfection. The idea is to now match the cost of mitigating controls with the risk assessment conclusions to ensure that you are not only addressing the highest priority risks, but you are also doing so at an appropriate cost.

Cost is not just capital expense (i.e. technology), it’s resources (existing, or additional), down-time, and so on. Whatever is required to meet the goals of the business are prioritised and an implementation plan created and given to the Governance committee. It is their responsibility to ensure that not only are the current business goals (and possibly the future as well) met by the proposal, but that the estimated cost of doing so does not exceed the value of the data.

So now you know what you need to do, the order in which they are to be achieved (hopefully in parallel), and who is going to run the project (or projects).

Now you have to decide HOW you are going to achieve the goals, and I HIGHLY recommend it’s done in this order;

  1. Adjust your non-technical business processes to remove both the requirement for, and the instances of, sensitive data. If you have no data, you have nothing to steal;
  2. Consider outsourcing the non-core function elements of your business to known-good vendors (e.g. if you’re e-commerce, outsource the payments piece to a 3rd party shopping cart);
  3. Review your infrastructure in detail, I can almost guarantee there are some efficiencies, or adjustments that can be made without the need for more technology;
  4. Buy more technology, but there are some VERY important consideration with this, and the choices you have should be driven by your business needs, and not by the brightest, shiniest toys.

The first three are too specific to drill down into, but for new technology to even be considered the following must be kept in mind;

  1. Are you going to manage it yourselves, or outsource? – If the former, you will need to ensure you actually have the skill-set to do so. Too often the device ends up sitting on the IT managers desk because s/he was pretty much lost after the sales engineers left. Or worse, they plug it in and leave it there un-patched, which is the primary basis for insecurity through technology;
  2. How are you going to monitor the device? – Does it have its own management station, or can it be integrated with an existing one, SIEM for example? If it has it’s own management station, how many will that make now for your organisation? 5? 10? More? The more GUIs you have, the less you will have the time to monitor and you will quite literally lose sight of what’s really important. Integration is key;
  3. Who will maintain the devices operationally? – Any security device is only as good as its tuning and optimisation, and this process is cyclical, and never ending, regardless of whether or not your business changes. The thieves never stop, nor can your baselining efforts;
  4. Will the technology you’re purchasing scale with the possible growth of your business? – Regardless of your short term goals, you will need to keep the businesses future plans in mind. There is nothing the business hates more than wasted investments.

I know I’m simplifying this drastically, but as I keep saying, security IS simple, it’s just difficult to achieve. Especially if you don’t get started.

Clearly there is a lot more involved in the due diligence necessary to make the right security control choices, but the above framework will fit the majority of businesses. All you have to do is fit it to YOUR business.

[If you liked this article, please share! Want more like it, subscribe!]

This begins a series of posts related to my theory of The 6 Security Core Concepts. I am assuming that The 4 Foundations of Security are either already in place, or at least being addressed in parallel.

So, in terms of cybersecurity, what is a risk assessment? According to Wikipedia it’s; “…the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized threat.”

NIST SP800-30 Revision 1 states; “Risk assessments are used to identify, estimate, and prioritize risk to organizational operations (i.e., mission, functions, image, and reputation), organizational assets, individuals, other organizations, and the Nation, resulting from the operation and use of information systems.”

Great David, now what? I know what a risk assessment is, I just don’t know how to do one!

There are 5 golden rules of conducting a risk assessment;

  1. Get Management Buy-In – I know, surprising huh?;
    o
  2. Agree on the Scope – region, department, business line, compliance regulation etc. Keep it simple or you’ll never finish;
    o
  3. Agree the Methodology & Deliverables – whether you use something based on methodologies such as NIST or OCTAVE, or a combination of many, agree the method up front and stick to it for ALL of your risk assessments;
    o
  4. Agree the Timeframe – from the beginning to the delivery of the results stick to the agreed timeframe, even if you’re not finished.
    o
  5. Get Started! – don’t get caught in ‘analysis paralysis‘

Once these are agreed, start your interview process, and again, don’t over-complicate this. Each department is going to have a different take on what’s important, and it’s not your job – yet – to argue priorities. You simply ask them what they consider to be the major threats to the business (from their perspective), and what is the likelihood of that threat being realised.

Bear in mind, this will not just be IT threats – IT does not corner the market – but it IS a big chunk of them; malware, data theft or other loss, network outage, Internet outage, server crash and so. That said, even such concepts as operational resilience have a majority foundation in IT systems, so that’s why the IT department have traditionally – and incorrectly – owned this process (if it exists at all).

Done correctly, the risk assessment will be driven by the Governance Committee (Core Concept 4), and have equal input from both the IT and the business sides. If not, it won’t have the management buy-in I go on so much about.

Once the data is collected, it must be put into some kind of perspective. This is where the words quantitative and qualitative come into play. Only very mature risk management processes should attempt quantitative, it’s simply too difficult for most organisations. Qualitative allows for better adoption by non-technical personnel, and will most likely speak better to the immediate needs of the business; i.e. reducing risk.

Assuming you’ve chosen qualitative, you must still put some value on the identified risks; 1 -5, 1 – 100, high-medium-low etc., as well as some indication of its likelihood of occurrence. For example; a planetary implosion would be catastrophic, but VERY unlikely. The payroll server going down has much less impact, but will occur more often, so should be the priority in this ridiculous example.

Now that you have your risks ranked in terms of impact and likelihood, you need to put some kind of monetary value on each in order to put the final prioritisation against it. It is VERY difficult to put $/£/¢ values against these risk rankings, but unless you do, you can’t prioritise, nor can you set the baselines required in your operational resilience (OR) / incident response (IR) / disaster recovery (DR) plans.

For example, if your e-commerce sites makes 100% of your revenue downtime is not an option. Therefore you not only need full redundancy in your systems and apps etc, and real-time monitoring of system health, you also need extremely robust SLAs against your 3 party vendors (hosting facilities etc.). Only this will ensure that both IR and DR processes are in line with your Business Continuity Management (Core Concept 6) plans.

You have those, right?

If it is determined that the risk is just too great for the organisation to stomach, you will move on to the next step in the process; Security Control Selection & Implementation (Core Concept 2). You will start by performing a gap analysis of your infrastructure to see where the gaps are between your current capability, and the agreed standards accepted by management in the risk assessment phase.

The purchase of technology is always the LAST resort! Business process review is the first, enhancing the capability of existing infrastructure is the second. Rushing to throw technology at gaps can lead to bigger problems as I have suggested in Insecurity Through Technology.

One of the themes I have running through my posts – other than the terrible grammar – is the concept of how not knowing where to start often leads to organisations doing nothing at all. As in every other instance, the way to avoid this issue is to ask the people who DO know. A good consultant will not only be able to help you design a risk assessment methodology for your organisation, they will be able to teach you to run it yourself. Remember, the role of your consultant is to teach, not just do.

Finally, like every other business process, the risk assessment methodology should be standardised across the enterprise so that the results are compatible with the business culture and comparable against each other. However, they should also be reviewed at least annually, or after significant organisational, change for continued suitability. As your organisation changes and adapts to the future business environment, so must your risk assessment keep up in order to stay relevant, and useable.

This post is not meant to tell you how it’s done (there is an infinite variety of risk assessment methodologies), but to ease the confusion that is still prevalent. Hopefully I have done that enough that you at least begin to ask the right questions.

Like all security, the risk assessment is simple, not easy, but simple.

To summarise;

  1. Don’t do ANYTHING until you’ve conducted a risk assessment, and this includes starting your PCI compliance project (if applicable). This is beginning of all security, and the initiation of all future business plans;
  2. Don’t over-complicate it, just choose your target, set a time goal and stick to it. Whether you are finished or not isn’t important, you can always get back to it later and reducing your risk as soon as possible is more important;
  3. Get an expert in the first time, learn from them;
  4. Don’t BUY anything until you know where it fits in, and how you’re going to manage it; and
  5. Unless the solutions you choose costs well under the estimated value of the data, don’t buy them, it’s career limiting.

[If you liked this article, please share! Want more like it, subscribe!]

So far I have focused on the Core Concepts of security, and how they are the basic building blocks of a security programme.  Well, – and to continue the cliched architectural analogy – these 4 things are the foundations on which those building blocks sit;

1. Management Buy-In / Culture – Hah, weren’t expecting that, were you!?  At least 3 of my posts have placed the vast majority of the responsibility – for everything from PCI compliance to customer service – firmly on the shoulders of the CEO (or equivalent).

Unless your company IS a security company of some sort, security is an expense, and whether or not that expense is seen as a business enabler (which it is) depends on the CEO’s attitude towards it.

Whether you’re starting an assessment at your client’s site, trying to implement a security program at your current employer, or interviewing for a job as a internal auditor, asking what the CEO’s attitude is toward security will determine the difference between success, and banging your head against the wall.

It may well be your JOB to change the CEO’s attitude toward security, if so, you’d better have a VERY good argument, and it had better involve making, or saving a ton a money (or making them look good …or both).

2. Policies & Procedures – Amazing how many people groan at this, and even security professionals cringe at the ‘paperwork’ they have to troll through.

That’s a shame really, because without that paperwork, you will never HAVE security. It’s your company’s instruction manual for how to do what you do, properly, responsibly, and securely.  Anyone who’s put together a chest of drawers from Ikea knows exactly what I mean; maybe, and I mean MAYBE, you could work it out for yourself, but how much more painful would that be?  It’s bad enough WITH the instructions!

Your policies and procedures let all employees know what to do, and as importantly, what NOT to do.  It’s enough that the thieves want to steal your data, why make things worse by not preventing your own employees from giving it away!?

3. Governance – As I have mentioned in previous articles, few phrases in security are perceived to be more ambiguous, open to interpretation, or complicated.

Wikipedia says; “Information Technology Governance is a subset discipline of corporate governance focused on information technology (IT) systems and their performance and risk management.”  It also says; “IT governance systematically involves everyone: board members, executive management, staff and customers. It establishes the framework used by the organization to establish transparent accountability of individual decisions, and ensures the traceability of decisions to assigned responsibilities.”

I can simplify this to; “IT Governance is the business side and the IT side having meaningful conversations.”  Group hug anyone?

It does not have to be complicated, it just has to be appropriate.  You don’t have to hire additional people to run it, you just have to assign the tasks, responsibilities, and accountability.  You don’t have to follow its decisions rigidly, all businesses have an exception processes (usually informal, and often consists of someone very high on the business side telling you to do something anyway).

IT, and especially IT security, are often seen as roadblocks to the business, and circumvented where possible.  The IT departments themselves are often just as much to blame for this.  IT’s job is to help the business do something right the first time, and they can only do this if they are in on the plans from the beginning.

4. Education & Training – While this is closely linked to policy and procedure, I’ve broken this out separately because of its importance.  You simply can’t expect non-security experts to keep up with the latest threats all by themselves, it’s not their job.  In the same way that I do not keep up with changes in the tax codes (that’s my account’s job), or the latest in social media advertising (that’s marketing’s job), everyone else relies on us to tell them what they need to know.

This training and ongoing education cannot become marginalised, and must be kept fresh and interesting.

If your security programme is not where you want it to be, or you are frustrated at the lack of progress, there is a very good chance that one or all of these foundations is missing.

I’m not saying you can’t hope to make ANY progress, but it will be needlessly inefficient, time consuming, and expensive.  Not to mention much harder to maintain.  I have only ever seen organisations achieve Business As Usual security when all 4 of these foundations is in place.

I will be individually expanding on the 6 Security Core Concepts, and putting them into context with these foundations.  Eventually I hope to provide more specific guidance on how to take this theory and put it practical use, but it’s time for dinner…

[If you liked this article, please share! Want more like it, subscribe!]

One of my favourite quotes from The Dark Knight; “You know what I’ve noticed? Nobody panics when things go “according to plan.” Even if the plan is horrifying!”

A little dramatic perhaps – not to mention some of the best acting of all time – but this directly applies to customer service.

Your clients don’t get anywhere near as angry if you come to them with a potential issue, it’s when they have to constantly chase you for resolution of a KNOWN issue that things go horribly wrong.  If your customer service is only ever reactive, you have failed, and if you can’t even react well, you are out of the game.

From my favourite website ever, www.despair.com;

customerdisservicedemotivator

Type in the phrase ‘customer service’ into Google and you’ll get over 8 BILLION results. There are institutions and college degrees dedicated to it, books by the thousand, and articles and blogs by the million (this one is very good; 8 Rules for Good Customer Service, by Susan Ward), yet how do organisations STILL get it wrong?

That’s easy, blame the CEO (or equivalent).

Just as a lack of a security culture is the CEOs fault, lack of a Customer Service culture is every bit as much on their shoulders.  As I stated incessantly; “Let’s be very clear; The CEO sets the tone for the entire company: its vision, its values, its direction, and its priorities.  If the organisation fails to achieve [enter goal here], its the CEOs fault, and no-one else’s.”

Replace “enter goal here” with “Customer Satisfaction”  and the rest is the same.

The symptoms of the inability of some organisations to provide good customer service (the CEO being the cause) can include;

  1. Poor selling techniques – if salespeople are not trained to sell only what the customer needs (not wants or even asks for), the organisation behind this salesperson will be unable to support the customers questions.  I don’t care how nice you are, or how great your products, if you’ve sold something the client doesn’t need, they will rarely buy from you again;
    o
  2. Poor products or services – there’s a fairly good chance that if your vendor does not provide good customer service, the other services and products provided by them are suspect, and should be reviewed.  Do your research, and ALWAYS ask for a proof of concept (POC) before you buy.  No POC, no purchase;
    o
  3. Black-hole communication – No-one wants to be yelled at, so if your calls and emails are going unanswered, there’s a very good chance you aren’t going to like the answer when you finally get them.  This is also an extension of 2.  And finally, forget how quickly the salesperson comes back to you BEFORE the sale, how are they immediately after?;
    o
  4. No Customer Service SLAs built in – in other words, if you have to ask for SLAs related to communication, or even something as simple as response times, there’s a good chance you won’t get the service you’re looking for;
    o
  5. Very low renewal rates – include this question in your RFP for new services and products, and have them prove it;
    o
  6. Limited, or no references – this one is too obvious  to expand on, but ignore industry awards, they are a farce.

An organisation that truly embraces a customer service culture will probably allude to it in their Vision Statement, and almost definitely in their Values.  Do business with only those organisations that take the term ‘partnership’ seriously, especially in security, and ANY company that bandies around the phrase ‘Trusted Partner’ needs to be taking client satisfaction to the next level.  Are they?

Good customer service is even simpler than security, and far less difficult to achieve, you just have to treat it as a foundation of doing business.  Your clients happiness is more important than your profit.  If you don’t believe that, you don’t care enough about them to give them what they need.

In one respect or another, we are ALL customer service reps, and this (to me) is the definitive guide to being a good rep; How To Win Friends And Influence People, by Dale Carnegie.

Yes I’ve read it …twice, and yes, I still have a lot of work to do 🙂

[If you liked this article, please share! Want more like it, subscribe!]

Some time ago I gave a presentation on BrightTalk titled ‘Insecurity Through Technology: Back to Basics‘ with the premise that the uncontrolled purchase of security technology to satisfy a perceived need may actually INCREASE your risk (go to Downloads if you just want the presentation).

Despite the crayon-esque diagrams, and the majority focus on PCI, I wanted to expand upon this concept in light of my current focus on simplifying security into “core concepts”, “appropriate / proportional security”, and “business-first”.

PCI lends itself as the perfect example of how a perceived need for technology can result in some very poor purchasing decisions.  Just look through the 12 sections of the PCI DSS and you may, in some form – and if you’re very unlucky – need ALL of the following; firewalls / routers, encryption, anti-virus, web application firewall, access control mechanisms, physical security measures, logging mechanism, vulnerability scanning, penetration testing, wireless scanning, file integrity monitoring, and a ton of ‘paperwork’.

All too often budgets are spent on items such as these at the beginning of a compliance project instead of when, and IF it’s really necessary. A lot goes into a compliance before you should be buying anything other than expert guidance or an education series.

The problem is on both sides of the sales process. The salesperson only knows how to sell either what they are being asked for, or more usually, as much as they possibly can. The purchaser has probably not done their proper due diligence and is asking the wrong questions. The best way to resolve this is if at least one side of the equation is aware of the The 6 Security Core Concepts, and follows the established good practice for the institution of a security program.

Analogy; If your doctor tells you you’re going to require an operation, you will of course learn all you can about the procedure. You may even become something of an authority in your condition (to laymen anyway). What you will NOT do is try to perform the operation yourself. Why would you treat cybersecurity any differently if you’re not an expert?

Know enough to ask the right questions, then let the experts take over. How do I…

  • choose the right technology?
  • ensure it can be integrated with current processes?
  • manage and monitor it?
  • measure it?
  • show the benefit to senior leadership?
  • …and so on…

If new technology is not properly configured, baselined, monitored, and maintained, you have added another potential vulnerability to your infrastructure. Any appliance is just another hardened server running an application of some sort, and should be treated the same way as the ones you build yourself.

Also, the more data you receive the more important baselining and tuning becomes, as you don’t want the important stuff to be obscured under layers of false positives. I do not believe there is room for Big Data analysis in security (per Don’t Get Me Started on ‘Big Data’), so integration of new technology with less-is-more security processes is paramount.

This has been, and will continue to be a theme throughout my blogs; 1) don’t buy anything until you know why you need it, 2) install nothing in production until you have figured out how to use and manage it, and 3) integrate all processes around it with a single overarching operations centre.

The threat landscape is intimidating enough without making things easier for the bad guys.

[If you liked this article, please share! Want more like it, subscribe!]