10 Steps to Successfully Manage Data Breaches

 In 66% of incidents, the breach went undiscovered for a month or longer.

It is paramount that your organisation responds quickly and efficiently when your organisation experiences a data breach.

We’ve simplified a 10 step process to help you respond to a data breach. If you think your systems have been hacked, please contact our 24/7 security team immediately at solutions@nettitude.com


Preparation is the foundation of data breach management. Statistically speaking it is close to absolute certainty that if you are a computer networked organisation then you will be attacked. As society becomes more computer literate and the availability of free hacker tools increases, the chances of one or more of those attacks being successfully also increases. Having an Incident policy and plan is the first step in preparing for a data breach, however additional activities should be taken. Review logging capability and configuration across your organisation to see if it can be leveraged to assist in any future data breach investigation. Conduct a criticality assessment of your assets and document your findings. Carry out a threat analysis to understand what threats that your industry sector faces and what tools, techniques and procedures your adversaries will use against you. Make sure you also have an up-to-date network diagram in place.

Nettitude have produced a step by step guide on planning for a data breach – read it here: https://www.nettitude.co.uk/10-steps-to-prepare-for-a-data-breach


Gain some assurance around your preparations. At the very least you should test your Incident Response (IR) plan. This can be in the form of a table top exercise or a more sophisticated simulation based on your threat analysis. The objective is to ensure that your IR plan is fit for purpose and robust enough to deal with a broad range of scenarios. Further tuning of your IR plan will be performed in step 10.


Your ability to detect data breaches will largely be dependent on the people, processes and technology within your organization. Ensure your staff undergo training that will allow them to identify potential malicious activity. Your IT staff should have processes in place to review log data that you configured in step 1 to identify anomalous entries that might be worthy of further investigation. Similarly, logs from IDS/IPS, anti-virus and other security products should be reviewed regularly for anomalies. A robust process for log reviewing would be to automate that process by implementing a SIEM solution.


Any indications of a potential breach will first have to be triaged to establish if the indication was a false positive. First responder training should be given to IT staff who can undertake this type activity. Any confirmed incident will need to be classified with reference to its potential impact and prioritised based on its classification. Part of the prioritisation process will be to identify any specialist skills that will be required to effectively investigate the incident. Your preparation in step 1 should have identified pools of specialist skills that you can call on in the event of a security incident.


If you are in a corporate environment, and you don’t employ an incident response or forensics team, we would recommend that at this point you contact external assistance.

The external assistance should be a reputable organization that has both forensics and incident response capability. The following organisations have guidance on entities that can deliver strong forensics and Incident Response capability.

USA – Federal government – CIRA

UK – Central government – CIR

UK and US commercial sector – CREST CSIR

The investigation should have clear objectives set, such as establishing the scope and impact of a breach and determining the root cause of a breach.   Any IR capability should be backed with malware analysis capability. Make sure that any third party investigators are aware of any logging capabilities that you developed in step 1.


It will be necessary to try and contain the incident, that could be something simple like removing a network cable (make sure to record the active network connections on impacted systems before doing this) or something much more drastic such as completely shutting down a critical system. In the latter case, your Incident Response plan should specify who has the authority to authorise such a shut-down and under what circumstances.


Once the breach has been investigated and contained, you can start the process of eradication of the threat. This may involve the disabling of compromised user accounts or removal of malware. Once again, robust preparation should help you in this step. Do you have a policy applicable to actions on systems infected with malware? Does that policy differentiate between different types of threat i.e. is the policy the same for PUP’s such as unwanted browser add-ons and ransomware. The severity of the threat should dictate your eradication policy.


Determine how systems can be recovered. This could be achieved through restoring critical systems of files from a backup, or it could be achieved through a full systems rebuild. The specific approach for recovery will vary according to the type of attack, and the time sensitivity of the systems that have been compromised. It is important that, where practical, forensic images are collected of from impacted systems prior to the commencement of the recovery process. This will facilitate opportunities to perform much deeper analysis once your systems have been recovered. Such analysis may assist in determining who attacked your organization and what vulnerabilities they exploited to gain access to your network.


You may have legal and ethical obligations to notify various parties if data is compromised during a breach. Establish which parties need to be notified and under what circumstances. Again, if you have prepared effectively you should already have a list organizations and individuals that you will need to contact in the event of a data breach. If data is compromised during a breach, involve internal stakeholders such as PR and HR, if it is employee data stolen, at an early stage.

Follow up

If an organization is compromised, it is important that they understand what happened and when it happened so that an improvement plan can be formulated. The improvement plan should be based around a post-incident review that will examine how all of the previous steps were managed and what lessons can learnt. Gaps in capability around your people, process and technology should be identified and remediated at this stage.


To contact Nettitude’s editor, please email media@nettitude.com


10 Steps to prepare for a data breach

Every day, over 3 million records are compromised from companies around the world. The fact is that cyber threats are no longer a question of IF, but WHEN, a breach will occur. It is vital for your company to have a cyber security plan in place so that you are ready to act if your organisation experiences a data breach.

We’ve simplified a 10 step process to help you prepare for an attack. If you think your systems have been breached, please contact our 24/7 security team immediately at solutions@nettitude.com.

1. Change your mind-set

3.04 million Records compromised every day

126,936 records compromised every hour

2,116 records compromised every minute

35 records compromised every second

Information Security has traditionally focussed on securing the perimeter of the network. With the evolution of mobile devices, the perimeter is becoming less well defined. In addition, attackers are increasingly able to evade perimeter defences. Nevertheless you should still continue to focus on defending your network, but not exclusively. You should bring breach detection and Incident Response readiness into your defensive repertoire. If you get into the mind-set that you WILL be breached, you will prepared in the event of one.

2. Produce Incident Response Policy & Planning Documents

99% of computer users are vulnerable to exploit kits (software vulnerabilities)

Preparation is the foundation of data breach management. Statistically speaking, it is close to absolute certainty that if you are a computer networked organisation, then you will be attacked. As society becomes more computer literate and the availability of free hacker tools increases, the chances of one or more of those attacks being successful also increases. Developing an Incident Response policy and planning documents is a critical step in preparing for a data breach.

3. Do you know all your valuable Assets?

52% of the 2016 data breaches, the exact number of data records were unknown.

Assets are at the heart of any company and need to be maintained and secured correctly to help minimise the chance of an attacker accessing them. Follow the below steps to keep your assets secured:

  • Develop a full asset register that is regularly updated.
  • Identify the critical assets in your organisation and develop a risk profile for each of those critical assets.
  • Establish the threats to those systems and understand the impact of any degradation of availability of them.
  • Ensure that, wherever possible, that you have failover capability for critical systems and that persons with authority to approve the taking critical systems offline, are identified.

4. Update your Network Diagram!

In 60% of cases, attackers are able to compromise an organization within minutes.

One of the first items a Certified Incident Response Team (CIRT) will ask for is a network diagram, so make sure you have an up-to-date network diagram in place. Identify internet facing systems, especially those that will accept user logon credentials. Care should be taken when storing this document and access to it should be strictly limited, as the information in it is of high value to attackers.

5. Simple Threat Intelligence

In 2016, there have been 454 data breaches with nearly 12.7 million records exposed.

A threat intel/analysis exercise needs to be carried out to understand what threats your industry sector faces and what tools, techniques and procedures your adversaries will use against you. This information can be leveraged to better protect your critical assets and develop detection rules for the tools and techniques that your attackers will be using.

6. Strategic Partnerships

In 93% of breaches, attackers take minutes or less to compromise systems.

Establish partnerships with both internal and external organizations who can assist you in a breach. The fundamental departments to include in this are HR, Legal and PR departments in your Incident Response testing and education programmes.

Identify third parties who can provide specialist assistance during a breach and external parties who will need notifying in the event of a breach. If you are able to, develop information/intelligence sharing with other organisation in your business sector. Establish if your local Law Enforcement agency has a computer crime unit and have their number on hand in the event of a serious data breach.

7.  Have you tested your plan?

Only 38% of global organizations feel prepared for a sophisticated cyberattack.

Gain some assurance around your preparations. At the very least you should test your Incident Response (IR) plan. This can be in the form of a table top exercise or a more sophisticated simulation based on your threat analysis. The objective is to ensure that your IR plan is fit for purpose and robust enough to deal with a broad range of scenarios. Learn the lessons from such tests to remove any weaknesses or gaps in your Incident Response plan.

8. Educate your staff

30% of phishing emails are opened. And about 12% of targets go on to click the link or attachment.

Educate your staff around matters relating to incident detection and response. End users should be trained to identify suspicious activity and phishing scams. They should also be trained to report suspicious activity and the reporting method should also be referenced in your IR plan and ‘Acceptable Use Policy’. Educate IT staff to triage suspicious incidents and understand how their actions during triage can impact on an Incident Response investigation, this should include how and who to approach in this instance,

9. Monitor, Log & Collect

63% of confirmed data breaches leverage a weak, default, or stolen password.

Review logging capability and configuration across your organisation to see if it can be leveraged to assist in any future data breach investigation or used to detect intruders inside your network. The log review should encompass application logs, security appliances and management software such as Group Policy. Develop retention policies for log data develop processes for managing large volumes of log data.

10. Detect the breach!

In 7% of breach cases, the breach goes undiscovered for more than a year.

Your ability to detect data breaches will largely be dependent on the people, processes and technology within your organization. Your IT staff should have processes in place to review log data that you have configured in your environment in order to identify anomalous records that might be worthy of further investigation. Similarly, logs from IDS/IPS, anti-virus and other security products should be reviewed regularly for anomalies. A robust process for log reviewing would be to automate that process by implementing a SIEM solution.

Ready to take your organisation’s cyber security to the next level?

Nettitude provides a variety of services to keep your company safe from cyber threats. Speak with a specialist today by emailing us at solutions@nettitude.com.


To contact Nettitude’s editor, please email media@nettitude.com.

PCI DSS v3.2 – The One Year Countdown has begun! Again?

I am sure many of you are reading this title thinking “what is he talking about, v3.2 went live ages ago” and you would be correct, however version 3.2 of the PCI DSS continues with the concept of future requirements, meaning the one year countdown to the 31st January 2018 has begun.

Save the date

The PCI Security Standards Council introduced nine requirements in PCI DSS v3.2 which are best practice until 31st January 2018, after which time they become mandatory.

Now let’s be realistic, the majority of merchants and service providers are going to treat ‘best practice’ as ‘optional’ until they undergo an assessment after 31st January 2018; but please don’t wait. Compliance is not just the assessment with the Qualified Security Assessor (QSA); we should be striving to meet every requirement, at all times and they must be in place by the 31st January 2018 even if your assessment is not until after that date.

Do I need to do something now?

YES! The majority of these future dated requirements are for Service Providers, so if you choose to postpone doing something about them now, this is going to be highlighted in your Attestation of Compliance.

In this hyper-competitive world, can you afford to show this to your clients and the payment brands? Will it make the difference when touting your wares? If I was looking for a service provider, part of my due diligence requirement (12.8.3) would be to see how you’re doing with your future dated requirements.

Don’t forget, you have not only got these requirements going mandatory, you may also have the GDPR on the horizon too. So let’s get planning.

What are the requirements?

The table below was compiled from the PCI DSS v3.2, so be sure to get the full requirements from there:

Requirement Details Service Provider only?
3.5.1 Maintain a documented description of the cryptographic architecture. Yes
6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable. No
8.3.1 Incorporate multi-factor authentication for all non-console access into the CDE for personnel with administrative access. No
10.8 Implement a process for the timely detection and reporting of failures of critical security control systems. Yes
10.8.1 Respond to failures of any critical security controls in a timely manner. Yes If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods. Yes
12.4.1 Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program. Yes
12.11 Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Yes
12.11.1 Maintain documentation of quarterly review process to include: – Documenting results of the reviews – Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program. Yes

…and that means I have to do what?

Some of these requirements are nothing but forcing you to employ good practice. On first look this seems cheeky perhaps, but if it is good practice you can hopefully already demonstrate this either within your self-assessment or to your QSA.

3.5.1 – Documenting your cryptography

This is not a daunting as you might think. It is only going to apply to your organisation if you are storing encrypted cardholder data, and if you are a service provider; so you might be off the hook already. Pragmatically, this is only an extension of 3.6 so review that documentation and add details accordingly.

6.4.6 – This is an extension of change control

Possibly the EASIEST of the future dated requirements. Why you say? Because it is just good change management. If you are achieving a good change management posture, this goes without saying that you will be ensuring that PCI DSS compliance is being maintained on all changes, let alone those deemed ‘significant’.

Review the process, insert a reminder/action/decision point to say “Is this significant? Was all affected documentation from this change updated appropriately” and record.

8.3.1 – Multi-factor Authentication for Non-Console Administration

This could be an awkward one. Here’s the problem for Admin’s – sitting at the machine in the CDE, don’t need MFA to logon (but I won’t complain if you have it!). Sitting elsewhere and connecting to the CDE to administrate it, you will need something. Start planning now if this is not in place as it will affect a number of requirements and likely to attract the attention of 6.4.6 above.

10.8 & 10.8.1 – Find out that it is broken, why it happened and fix it without delay

This one is for service providers only – but once again I will not object to Merchants doing it too! You need to show how you are monitoring the monitoring systems for failure. This can go hand in hand with testing your incident management processes, particularly for things which do not get tested on a daily basis. Work out a control test to apply to each of those system where appropriate. If the monitoring processes do their job, you will not only be giving yourself evidence of testing the incident management plan, but you have checked the monitoring systems itself is working – Segmentation Testing

This is a recurring activity to test your segmentation, only for service providers too. Check the requirements in the standards and have it done, either by an independent qualified resource, or engage the services of a penetration testing company.

12.4.1 – Executive Management and a PCI Charter

This is new, and not entirely unfamiliar. If you are running an ISO 27001 ISMS, you will know about Top Level Management needing to be part and parcel of the programme. A RACI matrix here will help, along with keeping top management in the loop; this requirement is a good place to start if you have not already.

12.11 & 12.11.1 – Perform reviews

Again, this is not a new idea but a real boost for maintaining compliance. Thinking again about ISO 27001, you are doing internal auditing as that is mandatory, then it is a control to go into your management system and you are covered. It is about assessing that you are performing BAU activities and can evidence this, so some evidence that change controls and BAU activities were observed in place and effective and that documentation evidence exists of such a review.

So it is all quite straightforward?

Yes – a general review of your day to day activities is going to ‘smash these out of the park’. And if you are struggling with where to start, contact your QSA Company for assistance; they will be happy to help.

If you have done nothing yet, please try and minimise your delay. Also, remember that these are all requirements designed to minimise risks, so pop an entry into your risk log (requirement 12.2) and as you work through them, drop them off; the assessment process will love you for it!

P.S. Save the Date – 31st January 2018, not only is it a significant day for PCI DSS, it is also a total lunar eclipse and in the UK we sadly don’t get to see too much of it.


To contact Nettitude’s editor, please email media@nettitude.com.

Soldier to Cyber

As an ex-serviceman myself, I’m often approached by numerous service leavers who’ve asked how they can best prepare themselves for a career as an IT Security Consultant (AKA Penetration Tester / Ethical Hacker).

I’ve created this post based entirely on my personal experience. The aim is to provide guidance to those, who like myself, intend entering this exciting and fast evolving industry as a complete beginner.

It was two years after leaving the Armed forces when I realised the career path that I wanted to take, and this realisation came after much deliberation into what actually motivates me. Unfortunately, as a result of this delayed realisation and lack of calculated direction, I didn’t effectively utilise my time in resettlement. Of which, I’d strongly recommend using the whole year to get the very most out of it! Resettlement is one of the most joined up processes the military offers, providing you apply thought to what you want out of it. I would encourage anyone in resettlement seeking a career as a Security Consultant to utilise all available opportunities and look into the training programs explained below.

  1. Sign up to the CTP (Career Transition Partnership) website and enrol on the CompTIA A+ course (10 days). Now I know what you may be thinking “A+ is primarily hardware related” and you would be right. But A+ also covers a lot of the basics such as virtualisation, networking and security practices – These “basics” will become part of your everyday working life as a Security Consultant. Besides, you’ll also become a competent IT Technician, armed with the skills and knowledge to repair your own PCs/laptops; saving yourself £££’s in the future. It will also prepare you for course number 2, outlined below.
  2. CompTIA’s Network+ and Security+ course (15 days). This course is designed to look into networks and then security best practices (both topics are vitally important as a Consultant, because you will need to advise your clients on how to remediate their security failures). It is during this course where you will begin to learn about testing network security with pen testing tools. I would also take the time to invest in attending the exams for any courses to gain your formal certification. This will impress any potential employer, whilst also demonstrating your commitment and aptitude. CTP receive a preferential discount on CompTIA exams to encourage ex-servicemen and women. Consider using your annual SLC to fund these exams.
  3. Sign up to Cybrary.it and study the Linux+ course. This is VITALLY important because the tools you will be using in the future as a Consultant are likely on the Operating System (OS) Kali Linux. Before you start to use Kali Linux, you really need to understand how a Linux OS works. Cybrary’s Linux+ course does just that. Don’t just give the course lip service, it’s so important to get used to the functionality of a Linux OS – You really need to understand exactly what you are running. Practice, practice, practice; this will save you so much pain in the long run.
  4. The allocated resettlement/GRT shouldn’t be viewed as “buckshee holiday”; you should be using this time to apply your technical knowledge in a practical way and applying to potential employers for work placements. Things like accommodation and travel, as well as food are all covered when you are using GRT for a work placement (I will caveat that with, this was the case 3 years ago).
  5. Using the whole year, this would take you into roughly 6 months of resettlement and you’d have gained the basic skills to further your development. It is now you should consider using one of your resettlement grants towards a course provider who offers CREST training in Penetration Testing / Ethical Hacking in order to work towards the CRT (CREST Registered Tester) exam. The fact you are leaving the military most likely with SC, or DV and a CRT qualification will make you highly desirable.
  6. You will now be armed with plenty of skills and certificates to be considered for a Junior Tester position. Whilst you’re applying for jobs or just seeing out the end of your time in the Armed Forces, download vulnerable Virtual Machines; Metasploitable2 is a great start. It’s purposely designed with plenty of security flaws to exploit and test your newly learned skills. Alternatively, there are plenty more vulnerable VMs.
  7. Should you want to excel and go above and beyond it would be worth considering studying for the OSCP (Offensive Security Certified Professional) exam. The OSCP certification is regarded as the best within the Pen Test industry. By successfully completing the OSCP certification, the holder will have clearly demonstrated their proficiency as a Penetration Tester. This course costs around £1200 and is a difficult course that requires 100% commitment.

Embrace learning! The industry is constantly evolving and I haven’t stopped learning and I don’t think I ever will. Ensure you utilise your resettlement package wisely and invest the time and effort to prepare for your future.

I wish you all the success in your future. Please feel free to drop me a message should you need further guidance.

To contact Nettitude’s editor, please email media@nettitude.com.

The Big Freeze Is Coming – PCI DSS and change freezes

With the festive period rapidly approaching, many people will no doubt be looking forward to an extended break and some well-earned time away from work. The run-in to Christmas can be a relatively peaceful time of the year for many people, with organisations reluctant to kick-off large projects, or make significant change at a time when their employees are taking leave.

Many businesses will implement, what is referred to as, a change freeze over this period; completely stopping all but the absolutely unavoidable, hoping to minimise the risk of unexpected downtime. After all, nobody wants to be rolling back a system upgrade on Christmas Eve, or recovering backups on Boxing Day.

Probably the most common justification for a change freeze is found in the retail sector. With the Black Friday madness now behind us, the busiest shopping day of the year is predicted to be December 23rd. Crowds of hopeful last minute shoppers are expected to rush to the high-street, and possibly even more will go online and put their trust in next day delivery.

It’s at this time of year, where the impact from any technical glitches will likely cost more than at any other time. Last year, over a third of all shoppers waited until the final week before Christmas to complete their shopping, resulting in a significant loss for any retailer whose website or shops are unable to satisfy their customers desire to spend.

It’s easy to see why those tasks, considered not to be “absolutely unavoidable”, are delayed. Updates, upgrades, migrations, new installations – they’ll have to wait until January. But this can prove to be problematic, especially if your business is trying to comply with PCI DSS.

There are many ongoing requirements that must be met to maintain PCI DSS compliance, and some of them could fall victim to the change freeze. The most significant issue is applying critical security updates within one month of their release. In my opinion, PCI DSS is already very forgiving on this requirement, arguably one month is an overly long window in which to apply a critical security update. However if your business runs a change freeze from mid-December until January, failing to install updates could leave you (and your Qualified Security Assessor (QSA)) with a problem, come the time of your next on-site assessment.

Any organisation which enforces a change freeze that might impact on security (never mind compliance) should complete a comprehensive risk assessment. Consider what additional risks exist as a result of the freeze, and any mitigation work required (wherever possible). Make sure that you assess the risks of both making and not making changes, and use the same risk assessment process for a consistent result.

Keeping with the example of not installing security patches, you should consider the exposure of each system affected (a public-facing server versus an internal server), as well as the time immediately before and after the change freeze. It should go without saying that your ‘house’ should be in order prior to the change freeze, and that all patches should be applied and verified. Another recommendation is to complete additional vulnerability scanning to provide extra visibility and assurance.

While the change freeze is in place, your teams should be actively monitoring any alerting systems you have, as well as the security bulletins provided by vendors. If critical updates are released, assess whether they justify breaching the change freeze. If they don’t, then at the very least you should consider applying them to any test environments.

Schedule in any required maintenance windows in advance, and when the change freeze lifts, apply any critical updates to the most exposed systems first, and work back from there.
As for your PCI DSS and compliance, it’s important to “show your working”. Don’t simply hope your QSA won’t notice that some tasks haven’t been completed. Each QSA’s approach and expectations may vary, so work with them on an ongoing basis and at the time of your assessment, and show that you’ve acted appropriately.

Performing a risk assessment doesn’t have to mean pages and pages of documentation, but you should be able to demonstrate that you considered the risk and acted appropriately. You may also need to complete a compensating controls worksheet, but again this is something to discuss with your QSA. PCI DSS should never stand in the way of your organisation achieving its goals, and taking a pragmatic and open approach to this should help to ensure that the change freeze doesn’t leave you out in the cold.

To contact Nettitude’s editor, please email media@nettitude.com.

Drive My Information Security Car

Maintaining your vehicle

Modern day information security can be likened to vehicle maintenance; with a business being the vehicle and the various lubricants and fluids being the different forms of data and regulations. The Payment Card Industry Data Security Standard (PCI DSS), is just one example of these data types.

Figure 1: VW Beetle Cutaway

Figure 1: VW Beetle Cutaway

What happens if these different types of data are not maintained?

A simple ball exercise, with the different coloured balls represents different types of data, and the people represent the different processes required to move this data around a business. No rules = ANARCHY!

Figure 2: Data Flow exercise (Red=PCI; Blue=PII, etc.)

Figure 2: Data Flow exercise (Red=PCI; Blue=PII, etc.)

Okay, so PCI DSS v3.2 is much like your annual MOT (roadworthiness) test, with specific terminology for their testing criteria, for example:

1.1.1.a Examine documented procedures to verify there is a formal process for testing and approval of all:

• Network connections
• Changes to firewall and router configurations

Identify the document(s) reviewed to verify procedures define the formal processes for:

• Testing and approval of all network connections
• Testing and approval of all changes to firewall and router configurations

This is all somewhat confusing….

It is a given that most QSAs would expect every organisation that processes, stores or transmits cardholder data (or who it might impact) will fully understand the intent of all these specific controls.

However, the Information Security Consultancy (ISC) team at Nettitude takes a slightly different viewpoint and understands that not all companies can afford to employ the expertise of a master mechanic and may have more inexperienced apprentices who are running their information security departments. However, no matter what their expertise, the thing that these information security professionals have in common, is that ‘want’ to do their jobs to the best of their abilities and to ensure that the environments they support are as secure as possible.

Hence, Nettitude’s ISC team has been forged from members with wide-ranging skills and experience but that also have a commonality:

“To meet and maintain a minimum standard of skills, experience and expertise and the pursue excellence as standard”

In order to achieve these goals, the team is consistently scouring the web, white papers, industry standards and more to ensure that all of our knowledge is current and accurate.
As a result, we are able to impart this knowledge and provide myriad supporting references, enabling our clients to attempt to safely service and maintain their own motor vehicles.
More importantly, clients are empowered with the knowledge and can deal with regulators, auditors and their banks with confidence.

Creating your own service manual

Much like the motor industry today, there are resources available to assist you in creating your own ‘Haynes Manual’. For example, if I were needing to create a chapter, in support of 1.1.1.a, where might someone look?

Figure 3: VW Beetle Haynes Manual

Figure 3: VW Beetle Haynes Manual

How about in para 5.3, page 5-6, of NIST SP-800 ‘Guidelines on Firewalls and Firewalls Policy’?

“5.3 Test
New firewalls should be tested and evaluated before deployment to ensure that they are working properly. Testing should be completed on a test network without connectivity to the production network. This test network should attempt to replicate the production network as faithfully as possible, including the network topology and network traffic that would travel through the firewall. Aspects of the solution to evaluate include the following:”

How easy might it be to turn that paragraph into a policy statement, just through the use of the words MUST or SHALL?

Remember, PCI DSS is designed to provide a minimum baseline (defense in depth) for the protection of your card payment (or supporting) operations and uses industry guidance, such as NIST.


If you are struggling to understand the specifics of PCI DSS v3.2 (brake fluid) and how to effectively and efficiently maintain it within your company (VW Beetle, Porsche 911, etc.), why not have a professional come in and give your vehicle a well-earned service, by seasoned professionals?

Imagine the scene:

“You’re driving down the highway, at 70 mph, and you see the traffic in front is stopped. You apply the brake and NOTHING HAPPENS! At the time you need the brake fluid to operate as it is intended, it has been contaminated (integrity) or the brake reservoir is empty (availability)”.

It may turn out to be one of your best information security investments of 2017.

Authored by Jim Seaman, CISM, CRISC, QSA – Security Consultants Team Lead, Nettitude.

To contact Nettitude’s editor, please email media@nettitude.com.

Global statistics: An insight in to Nettitude’s latest honeypot findings

Knowing the methods, sophistication and modus operandi of threat actors, and how this changes over time is fascinating. The Nettitude Global Honeypot network has been upgraded recently to capture more in-depth information and more interactions from attackers. This section gives you an overview of the trends and highlights from recently captured data.

Remote Desktop Protocol (RDP) was developed by Microsoft to allow users to connect to a remote system over a network connection.

The end user will deploy RDP client software whilst the remote server will run RDP server software. The client software exists for Windows, Linux, Unix, OS X, iOS and Android as well as several other operating systems.
RDP services are built into Windows and are also available for Unix and OS.

The protocol has recently been exploited by the Apocalypse ransomware group. They brute forced weak RDP server passwords, gaining access to a victim’s infrastructure and encrypting files whilst gaining first-hand knowledge of network configurations. The data below shows that RDP is still a popular protocol to explore, with attacks originating from three separate continents.

Attacking RDP
The United States accounts for the vast majority of attacks against the RDP protocol (tcp/3389), as seen in Figure 1. The protocol is commonly used by system administrators to remotely access a users’ system to assist with troubleshooting. As previously mentioned, poorly configured RDP servers can offer a staging post for attacks against a system. With millions of endpoints utilising this protocol, it is not unusual to see attacks against it.

Attacker OS
Nearly 75% of attacks against RDP originated from Windows terminals, specifically Windows 7 or 8, as seen in Figure 2. This is consistent with the popularity of the RDP protocol, its compatibility with Windows OS and the likelihood that a victim has it supported on a Windows server.

Most attackers mainly use windows 7 or 8. Unlike attacks observed from the United States and Iraq, Iranian attackers focused their efforts against port 22 which provides the Secure Shell (SSH), Secure File Transfer Protocol (SFTP) and port forwarding, as seen in Figure 3. Iran, as a nation state, has significantly improved its cyber capability since the Stuxnet and Flame attacks in 2010 and 2012. Since the election of Hassan Rouhani to President in 2013, funding for cyber security has risen by 1,200% (between 2013-2016).

Iran has sought to harden its defenses and learn from the Advanced Persistent Threats (APT) campaigns that were directed at Iran. The Internet itself is less censored which has paved the way for an increase in malicious activity originating from, or routed through, Iran. As is seen in China, Internet Service Providers are leveraged by attackers to conduct attacks, be it automated or manually crafted campaigns. These allow for a certain level of anonymity.

Iraq has recently seen victims targeted by a group known as Operation Ghoul, a credential harvesting group that exploits victims using spear phishing emails. Interestingly, the attacks originating from Iraq, and captured by the honeypot, target port 3306 which typically hosts the MySQL database system, which can be seen in Figure 4. Databases are often a rich repository of information, with organisations often using it to store confidential material. For example, a poorly configured SQL database would afford attackers the ability to credential harvest and sell that information formonetary gain.

URL Statistics
One of the more interesting areas to investigate is Uniform Resource Locator (URL) information, specifically focused on the origins of malware. URLs themselves are the global addresses of documents and other resources on the web. They are also used as staging posts for launching malware.

Nettitude, through its global network of honeypots, has captured vast swatches of information that has helped us understand malware trends and identify the domains through which they are being hosted. Figure 5 lists the top ten worst ISPs for hosting malicious URLs. Between them they account for 79% of the total number of maliciously hosted URLs. It is difficult to ascertain the source of these campaigns, be that the actual threat actor or a compromised computer used as a bot, however it does show that ISPs are an ideal medium through which to launch malicious activity.

Nettitude has drawn on historical data and observed the creation of just over 139,000 malicious domains, as seen in Figure 6. Of those, just over 77,000 have been created since 2014, accounting for 55% of the total number observed. In 2015 alone, over 53,000 were created, a record number since data records began. This is a staggering statistic and one that is going to increase by the end of 2016.

This article has been taken from Cyber Threat Intelligence (CTI) Report produced by Nettitude’s Research and Innovation team. If you would like to request a copy of the CTI Report, you can request it here.

Authors: Phil Buck and Dr Jules Pagna Disso in Nettitude’s Research and Innovation team.

To contact Nettitude’s editor, please email media@nettitude.com.

The Accelerator Scheme

It’s no secret within the cyber security industry that finding the high calibre and skilled individuals required to deliver first class security services can be problematic. Ever determined to turn problems into opportunities, the big brains at Nettitude’s HQ in Tancred Towers brainchilded the Accelerator Scheme.

The Accelerator Scheme is a seven month, hands-on training course designed to help address the current skills gap within the cyber security industry and to provide a viable entry point for individuals looking to begin or develop a career within the IT security services sector. The programme is designed to provide education and practical exposure across a wide variety of security disciplines including penetration testing, malware analysis, vulnerability research/development, threat intelligence and incident response. On successful completion of the programme all candidates will be supported into full time security consultancy roles within the business….

Problem solved?! Well almost….

Taking the idea from its conceptual state, Nettitude’s marketing and recruitment department worked tirelessly to broadcast and advertise the new initiative, we wanted to sniff out and attract the best, wannabe security consultants from around the country via Nettitude’s website, social media and by attending hacking conferences scattered across the country.  Meanwhile, back at the office, the technical bods joined forces to hammer together and fashion a rigorous agenda that would provide tailored and relevant training. The importance of hands-on experience has not been lost within the programme and a high proportion is made up of ‘real world’ delivery under the careful mentoring and guidance of some of Nettitude’s senior security consultants.

A number of dedicated recruitment days were held where prospective ‘Accelerators’ were put through their paces via a series of team building and technical challenges. Only eight survived all of which were selected. J

…and on the Monday 12th September Nettitude were happy to extend a warm welcome to the ‘Accelerators’ both to the programme and to the business. The photos below were taken on a couple of team building days. One involved elements of self-awareness, understanding others and how to work effectively together (important in a 7 month programme!)….the other involved being locked up in a room for 60 mins and solving problems to escape….. followed by pie eating/beer drinking. Fair to say, both days had their merits and the team are forging some strong relationships!

For more information around careers at Nettitude click here:


Figure 1: Team Building Lying Around



Figure 2: A particular interesting flipchart



Figure 3: Escape live team 1



Figure 4: Escape live winning team 2


To contact Nettitude’s editor, please email media@nettitude.com.

24 x 7 SOCs: The Answer to your Monitoring & Logging needs?

Monitoring & Response:

A key aspect of your cyber assurance strategy that for many organisations has been around for years, but a strategy that has never really been addressed, or even acknowledged previously as a problem.

However, the recognition that cyber-attacks and breaches could now happen to anyone, is inevitably bringing the consideration of ‘situational awareness’ to the top of the pile.

  • But what do you need from a monitoring & logging solution?
  • What should a Security Operations Centre (SOC) provide for you?
  • How can you both demonstrate the value and return of your business?
  • Can you be assured that your environment is monitored for the wide range of threat actors, types of attacks and level of sophistication that may be deployed against you?

The SOC (Security Operation Centre) is the centralised hub for organisational logging and monitoring which can either be in-house or outsourced to provide visibility over technical and security issues. Having a SOC is key to understanding your organisational security posture in order to prevent and protect key assets.

We are going to explore some of these issues in a series of blogs. The industry has made a number of attempts to define ‘good’ for this area, but there are as yet no clear standards, expectations or buying help.

This will change, but in the meantime we are going to look at a number of key issues, starting with: Do you need a 24×7 SOC service?

Asking the right questions

Most organisations believe that by simply having a SOC 24 x 7 they have enhanced security and are better protected against threats and vulnerabilities, unfortunately this leads into a false sense of security. At Nettitude, this has been the issue of many debates.

On one hand, having dedicated analysts around the clock watching your environment sounds exactly the sort of thing that is required. After all, cyber-attacks don’t just happen between 9-5 in your particular time zone!

On the other hand, is this the overriding factor that will help you both detect and react to a breach in the best possible manner? What happens if your business is 9-5, who is going to respond at 2 am within your business? How much meaningful investigation will take place at that time? What about the capability of the SOC team? If you only have SIEM/Log analysis, who is going to responsible for the Incident Response?

The reality is that a 24×7 SOC itself is not the primary indicator of success.

The real questions that need to be addressed are ‘how good is your SOC?’, and ‘how can it be measured?’.

A SOC needs to be operating at the best of its ability, maturing well and constantly updating with threat intelligence, to include not just the latest emerging threats but also innovative ways of detecting new threats. A SOC needs to be able to operate at the same level as your adversary. If you are looking to provide assurance that means you can withstand a nation state or organised crime group from successfully attacking you, what capabilities and depth do you need within your SOC and IR teams? Does your SOC even have in-depth IR capability available?

A great SOC is not a standalone department, it needs full interaction with your cyber security assurance programme for optimal results.

Cyber Security Assurance

There are many areas that we can dive into, but the main areas that often get discussed are around the capability of a SOC are: Technology, People, Process and Information. To this we would add Threat Intelligence and frame this all in the context of Assurance (i.e. ultimately, confidence that you can detect and effectively deal with a breach when it happens).

Figure 1: Quality of SOC

The Financial Service sector has implemented the CBEST programme which takes the CREST STAR scheme and applies it to their industry. The foundation of this is the desire to provide a level of assurance to the UK financial services sector that they could manage a sophisticated cyber-attack. The use of threat intelligence, simulated testing and incident response maturity assessments are the key building blocks to achieving this.

Figure 2: CBEST & STAR

Within a SOC, proving that assurance must be a key objective.

So, before we dive into insisting on a 24×7 SOC, let’s look at the real issues that we should be looking for within any SOC service (in house, hybrid or fully outsourced).

Threat Intelligence (TI)

Having accurate TI is crucial when looking at detecting threat actors and activity. One of the first challenges of any monitoring & logging solution is the sheer amount of logs and data you will potentially have to deal with.

There are 3 areas this should help you with:

1. Identifying Threat Actors – Know your enemy! Who they are, but also how they operate and how likely they are to come after you. Threat Intelligence can help you identify quickly your highest priorities in terms of likely attacks to be seen, what assets they may be going after and how they may seek to attack.

2. Context of Risk – This must be understood in the context of risk. Remember your threats are a component of your overall risk, so make sure your SOC knows what your critical assets are, where they are and what vulnerabilities you may have so that they can act in an intelligent manner to help monitor them.

Figure 3: Risk Definition

3. Red Teaming – If you really want assurance then you need to simulate the very events you are trying to protect yourself from. Having a Red Team (penetration testing experts) that is integrated with training, and working alongside your SOC is vital. How will you know they will provide the capabilities you need, when you need it, if they have never experienced the right level of attacks?

If the information we base our threat on is incorrect, irrelevant or out-of-date, the chances are the high number of false positives will drown out the real threats. As threats constantly change, it can be hard to keep up and know where to look next.

Poor threat intelligence is essentially looking in the wrong direction which is the equivalent to not looking at all. It’s also an early warning sign: a little like people flashing their headlights at you to indicate an upcoming hazard, or speed camera. Use TI to help you know what is round the corner!

A good SOC must use true Threat Intelligence to inform, shape and define the service provided. This will be done at both the geographical, sector and individual level for each customer.

There are generally 3 ways in which SOC services are provided:

1. You may have/need a fully in-house provided capability including deep dive IR capabilities;
2. You may be looking at an in-house 1st/2nd line capability with an outsourced 3rd line/expert/IR extension, or
3. You may be looking for a fully outsourced model.

There are multiple components that need to be regularly monitored, tweaked, trained, educated and updated when thinking about a beneficial and reliable SOC that go a long way beyond ticking a box to say the SOC you have is 24 x 7.

SOC Maturity

There are then 4 areas that you need to look at within the core capabilities of a SOC that will help you determine if a SOC is good for you.

The SOC maturity is also crucial to the effectiveness and understanding baseline activities and anomalies. The SOC should also have a maturity plan assessing its current state, where it aims to be and how it intends to bridge that gap.

1. Information – All SIEM platforms correlate and take in data from log sources. How these are tuned, which ones are used, how effective they are to detect the type of activity you’re trying to detect, are all important. Incorporating information about the environment (key assets, vulnerabilities, threats, etc) is also key.

2. People – When looking at personnel within the SOC, it is important to recruit based on experience and certification, but also to assess capability. Although it may be tempting to employ graduates for all your roles, you will not gain the depth of experience needed to deal with the potential level of threat you need to monitor for.

What in fact you probably need is an experienced team with a variety of skill sets and experience to be able to address a wide variety of issues and concerns. Members of the team should also support the maturity process by helping to develop processes with regards to environmental tuning, be regularly trained and assessed to support the day to day running of the SOC.


Figure 4: Nettitude SOC

3. Tools/systems – The SOC tool set should be far more than just a SIEM platform (although this is a key element). The addition of host based agents, network captures, TI products, honeypots, etc is as important.

How effective and intelligent your SOC toolset is and how efficiently it is used will directly impact its utilisation. The SOC platform should not be considered a single or standalone SIEM product that will protect your entire organisational security. The initiative should be taken to see what other tools can be used in conjunction to generate more intelligent alarms and events for example, IDS/IPS as well as other state of the art cyber intelligence tools to work cohesively with the SIEM solution.

4. Processes – So what happens when you detect a threat? Is there panic and mayhem or is there a set process in place with an efficient escalation process specifically for that process? If they exist, how regularly are these processes reviewed? Processes in this context are a means of regulating different scenarios and the need to be reviewed, created, deleted or amended as required to ensure maximum efficiency. They do not apply just to alarm escalation but also day to day tasks which will allow regulate duties among team members.

So, what about 24×7?

So before you insist on 24×7 being the key factor in a SOC service, bear in mind that there may be some significant hurdles to cross to achieve this, and that the rewards vs the costs may not be the right decision for you. Staffing a 24×7 SOC is significant. Evenings, weekends and holidays all need to be covered. Finding enough work for the team throughout the night can be a challenge and remote working can be very demoralising. Managing staff handovers, conducting training and knowledge sharing between shifts all can be problematic.

Many SOC’s will operate their IR and deep dive capabilities during the day and on a call out basis.

The far more important first questions to ask are the ones outlined above. Ultimately, if these can be achieved then your assurance levels will be much greater. 24×7 on its own is no guarantee that you will have a high level of assurance.

If a SOC is working to optimal standards in the areas as outlined above, then there may be little need to have an eyes on screen service 24×7, as genuine threats would be correctly detected, classified and acted upon.


To contact Nettitude’s editor, please email media@nettitude.com