PC PORTAL

Experienced. Trusted. Solutions.

Incident Response

By

Security newsround: October 2018

We round up interesting research and reporting about security developments from around the web. This month: data breaches are up (again), help with hacks, incident response, attacks on trust providers and a numbers game.

Breach over troubled water

More than 4.5 billion data records were compromised in the first half of 2018. That’s a 133 per cent increase from last year and a staggering 1,751 per cent up on the first half of 2015. And if those stats aren’t scary enough, try this one: the total number of breached records equates to 291 every second, on average.

The findings come from Gemalto’s 2018 Breach Level Index. The company also found that the average records per incident is growing at an alarming rate. In 2015, the average was 276,936 records; by this year, the average stands at 4.8 million records per incident. The arrival of GDPR has cast a fresh spotlight on the risk of data breaches.

Common hacks and how to stop them

A new report throws the spotlight on commonly used hacking tools and ways of stopping them. The report is a joint collaboration between the cybersecurity authorities of Australia, Canada, New Zealand, the UK, and the US. The report gives an overview of tools that attackers are known to have used in recent incidents. They give the ability to plant backdoors or exfiltrate data, gain remote admin control of web servers or move laterally in compromised networks.

“The intel is designed to give enterprises a better awareness of what they’re up against so they are better positioned to prepare defences,” The Register reported. The report is for network and systems administrators, and anyone involved in incident response. It’s available free here.

Best practice incident response

Stuck for ideas to develop an incident response plan? The cybersecurity unit at the US Department of Justice might be able to help. It has updated its guide to best practice for victim response and reporting cyber incidents. The 25-page document includes sections covering pre- and post-event actions, as well as advice on what not to do. Also included: threat education for senior management, plus advice on engaging with law enforcement and with incident response specialist firms. It’s available to download at this link.

Breakdown of trust

ENISA has published its first full-year annual report about significant security incidents at trust service providers in the EU. The document covers all of the incidents during 2017 involving services that make electronic transactions more secure, like digital signatures and certificates, or electronic seals and timestamps. The report found that half of the security incidents rated as ‘severe’ and a similar number had impact across borders. The most affected services were e-signatures and e-seals. System failures and third-party failures were the most common root causes, each with 36 per cent. The report summary is here and the full report is free to download here.

Security’s search for meaningful metrics

Better security starts with knowing what you need to defend against; data beats anecdotes every time. The problem is, cybersecurity metrics suffer from inconsistency. An article in Defense One reports that NATO member governments have different ways of counting what constitutes a cyber attack. That’s a problem, says the article’s author Stefan Soesanto. “Without published standards and discernable metrics … warnings are of no real value to the public. We simply do not know whether 6,000 annual attacks against NATO’s infrastructure is a lot or whether any of the 24,000 attacks against the French MoD were serious.”

John Pescatore of SANS Institute compared this to the retail sector, which uses revenue loss from shrinkage as a more reliable figure than the number of attempted thefts. “That is why reports looking at actual damage like the Verizon Data Breach Investigation Report and Microsoft’s Security Intelligence report [well, parts of it], are much more useful than the numerous ‘billions and billions of attacks are being observed’ reports,” he wrote.

Better security through privacy audits?

Here’s one interesting fact to emerge from the news that Google was finally killing off Google+. (Not counting the fact that Google+ still existed, surprising many of us who assumed it disappeared years ago). Up to 500,000 Google+ user accounts were potentially at risk of exposing their data to external developers. Here’s the kicker: Google reportedly discovered the exposure during GDPR and privacy checks as part of its Project Strobe initiative.

Some reports led with Google’s decision not to disclose the flaw because the company feared it would lead to closer regulatory scrutiny. But would this have actually happened? Stripe’s Tommy Collison noted that although the data was exposed, it’s not technically a breach since Google claims no-one has misused the information.

Things we liked

ISACA has introduced a new programme to help people to acquire and prove skills in auditing cybersecurity processes, policies and tools. MORE

Why return on investment calculations might not tell the whole story when it comes to cybersecurity investments. MORE

Brian Krebs interviews Tony Sager, former NSA bug hunter and now VP at the Center for Internet Security about a very timely subject: supply chain security. MORE

Finland’s data protection authority has some great guides for data subjects, including this English-language document about how to make a subject access request. MORE

A new Irish initiative aims to put 5,000 people to work in the field of cybersecurity over the next three years by upskilling them. MORE

IBM launched a free cybersecurity learning resource aimed at girls, called ‘’Securing the Internet of Things’. MORE

 

 

The post Security newsround: October 2018 appeared first on BH Consulting.

By

Plan for potential incidents and breach scenarios, cybersecurity conference hears

Businesses should prepare an incident plan for security breaches in advance to know what resources they’ll need to deal with it. Speaking at the Technology Ireland ICT Skillnet Cybercrime Conference earlier today, Brian Honan said that running different scenarios can help businesses identify whether they’ll need assistance from IT, legal, HR or public relations.

Research from the Institute of Directors in Ireland has found that 69 per cent of SMBs claim they’re prepared for a data breach. Brian flipped that statistic to point out that this means almost one third of business owners have no such plan.

Never mind cyber; it’s crime

He also encouraged companies to report incidents like ransomware, CEO fraud or a website infection. “Don’t forget you’re the victim of a crime. In most cases, a cybersecurity incident is treated as an IT problem, not even a business issue or a crime. It’s a mindset change. It’s not separate to your business, it’s integral to it.” To help make that change, he suggested: “we should drop the name ‘cyber’.”

When businesses have to disclose an incident, Brian called on them not to use the phrase ‘we suffered a sophisticated breach’ – because most times, it’s not true. In many cases, incidents are due human error, or to bad practices like poor passwords. “If you’re using cloud email, enable two-factor authentication and educate people in using secure passwords. Encourage them not to click on suspicious links,” he said.

Other attacks exploit platforms like WordPress and Joomla. Businesses using those tools to run their websites need to continuously manage and update them, Brian said. “Many web vulnerabilities and threats like attack types like SQL injection are known about for over 10 years,” he said.

Steps to better security

Companies can take several steps to improve their security, such as establishing policies. “They’re very important – they set the strategy for the business and help everybody to meet it,” said Brian. Having systems to monitor and respond to suspicious activity is also essential. “Look at the physical world: you can’t guarantee your business won’t be burgled. It’s the same in online world, but we need to be able to detect when it happens,” he said.

The best security investment a business can make is in awareness training for employees, Brian added. These programmes educate staff about how to identify potential attacks, and how to handle information in a secure way.

He also encouraged businesses to disclose when they have suffered an incident, to help improve overall security. “Everybody will have a breach, there’s no shame in that, so let’s get over that and share information to help each other,” he said.

Tackling the cybersecurity skills gap

Research shows a high proportion of security breaches take months to recover from, which is partly due to an industry skills shortage. “The biggest problem we have is a lack of skilled staff in cybersecurity,” Brian said. The conference saw the launch of a new programme to train 5,000 people in cybersecurity over the next three years. The Cybersecurity Skills Initiative aims to address the shortage in skilled security personnel.

It’s worth asking whether the industry is open to candidates without formal degrees in cybersecurity or computer science. Brian said some companies may need to relax restrictive HR policies such as requiring formal degrees in security or computer science to attract the right people into security roles. Otherwise, they could be missing out on enthusiastic, experienced and skilled people.

 

 

The post Plan for potential incidents and breach scenarios, cybersecurity conference hears appeared first on BH Consulting.

By

AWS Cloud: Proactive Security and Forensic Readiness – part 4

Part 4: Detective Controls in AWS

Security controls can be either technical or administrative. A layered security approach to protecting an organisation’s information assets and infrastructure should include preventative controls, detective controls and corrective controls.

Preventative controls exist to prevent the threat from coming in contact with the weakness. Detective controls exist to identify that the threat has landed in our systems. Corrective controls exist to mitigate or lessen the effects of the threat being manifested.

This post relates to detective controls within AWS Cloud. It’s the fourth in a five-part series that provides a checklist for proactive security and forensic readiness in the AWS Cloud environment.

Detective controls in AWS Cloud

AWS detective controls include processing of logs and monitoring of events that allow for auditing, automated analysis, and alarming.

These controls can be implemented using AWS CloudTrail logs to record AWS API calls, Service-specific logs (for Amazon S3, Amazon CloudFront, CloudWatch logs, VPC flow logs, ELB logs, etc) and AWS Config to maintain a detailed inventory of AWS resources and configuration. Amazon CloudWatch is a monitoring service for AWS resources and can be used to trigger CloudWatch events to automate security responses. Another useful tool is Amazon GuardDuty which is a managed threat detection service in AWS and continuously monitors for malicious or unauthorised.

Event Logging

Security event logging is crucial for detecting security threats or incidents. Security teams should produce, keep and regularly review event logs that record user activities, exceptions, faults and information security events. They should collect logs centrally and automatically analysed to detect suspicious behaviour. Automated alerts can monitor key metrics and events related to security. It is critical to analyse logs in a timely manner to identify and respond to potential security incidents. In addition, logs are indispensable for forensic investigations.

The challenge of managing logs

However, managing logs can be a challenge. AWS makes log management easier to implement by providing the ability to define a data-retention lifecycle or define where data will be preserved, archived, or eventually deleted. This makes predictable and reliable data handling simpler and more cost-effective.

The following list recommends use of AWS Trusted Advisor for detecting security threats within the AWS environment. It covers collection, aggregation, analysis, monitoring and retention of logs, and, monitoring security events and billing to detect unusual activity.

The checklist provides best practice for the following:

  1. Are you using Trusted Advisor?
  2. How are you capturing and storing logs?
  3. How are you analysing logs?
  4. How are you retaining logs?
  5. How are you receiving notification and alerts?
  6. How are you monitoring billing in your AWS account(s)?

Best-practice checklist

1.    Are you using Trusted Advisor?
  • Use AWS Trusted Advisor to check for security compliance.
2.    How are you capturing and storing logs?
  • Activate AWS Cloud Trail.
  • Collect logs from various locations/services including AWS APIs and user-related logs (e.g. AWS CloudTrail), AWS service-specific logs (e.g. Amazon S3, Amazon CloudFront, CloudWatch logs, VPC flow logs, ELB logs, etc.), operating system-generated logs, IDS/IPS logs and third-party application-specific logs
  • Use services and features such as AWS CloudFormation, AWS OpsWorks, or Amazon Elastic Compute Cloud (EC2) user data, to ensure that instances have agents installed for log collection
  • Move logs periodically from the source either directly into a log processing system (e.g., CloudWatch Logs) or stored in an Amazon S3 bucket for later processing based on business needs.
3.    How are you analysing logs?
  • ​​Parse and analyse security data using solutions such as AWS Config, AWS CloudWatch, Amazon EMR, Amazon Elasticsearch Service, etc.
  • Perform analysis and visualisation with Kibana.
4.    How are you retaining logs?
  • Store data centrally using Amazon S3, and, for long-term archiving if required, using Amazon Glacier
  • Define data-retention lifecycle for logs. By default, CloudWatch logs are kept indefinitely and never expire. You can adjust the retention policy for each log group, keeping the indefinite retention, or choosing a retention period between 10 years and one day
  • Manage log retention automatically using AWS Lambda.
5.    How are you receiving notification and alerts?
  • ​​Use Amazon CloudWatch Events for routing events of interest and information reflecting potentially unwanted changes into a proper workflow
  • Use Amazon GuardDuty to continuously monitor for malicious or unauthorised behaviour
  • Send events to targets like an AWS Lambda function, Amazon SNS, or other targets for alerts and notifications.
6.    How are you monitoring billing in your AWS account(s)?
  • Use detailed billing to monitor your monthly usage regularly
  • Use consolidated billing for multiple accounts.

 

Refer to the following AWS resources for more details:

AWS Well-Architected Framework

What is Amazon CloudWatch Logs?

Definition of Preventative controls, Detective controls and Corrective controls – Fundamentals of Information Systems Security (David Kim, Michael G. Solomon)

 

Next up in the blog series, is Part 5 – Incident Response in AWS – best practice checklist. Stay tuned.

 

Let us know in the comments below if we have missed anything in our checklist!

DISCLAIMER: Please be mindful that this is not an exhaustive list. Given the pace of innovation and development within AWS, there may be features being rolled out as these blogs were being written ;). Please note that this checklist is for guidance purposes only. For more information, or to request an in-depth security review of your cloud environment, please contact us.

 

Author: Neha Thethi

Editor: Gordon Smith

 

The post AWS Cloud: Proactive Security and Forensic Readiness – part 4 appeared first on BH Consulting.

By

Here’s the missing ingredient in a solid security and business continuity plan

Security incidents can cast an unforgiving light on many organisations’ readiness. They highlight the need for security programmes that go further than just fixing things when they break.

Response has been security’s classic default reaction to an incident. Something is broken, so we need to fix it. But this misses a critical ingredient: resilience. If an important system fails, organisations need to know they can continue by using alternative systems, be they technical or manual.

Resilience, not just recovery

“Security incidents invariably lead to downtime. So it makes sense to focus on resilience in security programmes, not just detection and recovery. This way, a business can continue to survive and function even if key services are disrupted or temporarily unavailable,” says Brian Honan, CEO of BH Consulting.

Last year’s ransomware outbreaks were a classic case in point. FedEx’s TNT subsidiary shipped a $300 million loss following the NotPetya infection. It took weeks to restore IT operations fully, and deliveries and sales declined during this time. The NHS in the UK cancelled 22,000 hospital appointments as it struggled to cope in the wake of WannaCry.

Steps to resilience

Brian recommends that organisations should become more resilient by integrating incident response and business continuity. He suggests the following four steps:

  • Identify key systems and services for your business
  • Look at the key risks and threats to those services
  • Based on that risk analysis, identify the key areas to address such as single points of failure, inter-reliance of systems and interdependency of systems
  • Engineer ways to mitigate the impact of any potential failure, either through cybercrime or other means.

Once you start talking the language of risk, you’re talking the language of business, not IT. That’s why Brian recommends getting agreement from business owners as to how the organisation manages the risks that it discovers. Suppose the assessment stage uncovers a vulnerable system. The organisation has three choices: replace the system outright, upgrade the current version, or accept the risk that the business will be unavailable for whatever time it takes to recover from downtime.

Decision time for the business

Each option comes at a price, but it’s up to the business to determine the cost it’s willing to bear. “The security professional’s role is to give the business well informed data and analysis so that they can make the appropriate decision for the business. The CSO is chief security officer, not the chief scapegoat officer,” says Brian.

There’s still vigorous debate over the meaning of resilience in the context of information security. Kelly Shortridge of Security Scorecard recently wrote a lengthy and thoughtful post that’s well worth reading. Drawing on a range of examples from far beyond security, she says security has too often focused on robustness. “Resilience is ultimately about accepting reality and building a defensive strategy around reality,” she writes. Quoting the ecological economics scholar Peter Timmerman, she adds: “resilience is the building of ‘buffering capacity’ into a system, to improve its ability to continually cope going forward.”

Another word for resilience is flexibility. That’s arguably an incomplete definition too, but the term hints at an ability to bounce back from an interruption to something approaching normal service.

The post Here’s the missing ingredient in a solid security and business continuity plan appeared first on BH Consulting.

By

Using ISO 27001 to guide your GDPR breach response plan

Among the many changes GDPR will usher in, one of the biggest for many organisations will be mandatory breach reporting. From May 25, all organisations holding personal data about European Union residents must disclose a breach if it is “likely to result in risk to personal data”.

What’s more, organisations must report such breaches within 72 hours of discovering one. Reacting in such a short timeframe calls for a robust response plan. Unfortunately, experience to date suggests such plans tend to be conspicuously absent. The ISO 27001 Information Security Standard can help.

ISO 27001 can enable organisations to map an incident response plan that covers not just IT, but also people and processes. A good plan will cover the following steps:

  • Detect
  • Contain
  • Eradicate
  • Remediate
  • Recover
  • Review
  • Communicate.

Who implements the plan?

Incident response often falls solely – and unfairly – on the shoulders of the IT team. “It can’t just be the IT person’s job. It has to involve the whole business: this is a business risk and a business issue,” said Brian Honan. He added that GDPR applies to physical information, not just data on IT systems. Brian was speaking as part of a panel discussion on GDPR at the ISO 27001 Ireland event last week.

He recommended that a security response team should include representatives from information security, operations, HR, legal, PR, and facilities management. HR should be involved because if it’s an internal breach, the organisation may need to discipline a member of staff. Recovering from a breach often creates a fraught, high-pressure environment. HR can also play a role by helping to coach employees and manage their time. “Breaches don’t just happen between the hours of 9 and 5,” Brian said.

Involving a legal team is also important because organisations will probably need to deal with the appropriate data protection authority. “Speak the right language to the right people. You don’t want to open a can of worms by saying wrong thing to the regulator,” Brian said.

Sending the right message

Too often, organisations fall back on stock answers like “a sophisticated breach” when there’s little evidence to support the claim. Having PR expertise on the incident response team helps to ensure the organisation’s public statements are consistent, timely and truthful.

Brian also recommended including a representative from facilities management on the team. That’s particularly useful if a breach involved a break-in where CCTV cameras and physical security could prove vital.

“The key thing is, engage early with the business, find out what is important to them. Find out what you need to have in place. Establish relationships. Know who you need to contact in the regulator’s office or the supervisory office, find out what way you will contact them. And other relevant bodies you may need to contact. And think about what external expertise you may need. It’s important that you have those contact details already,” Brian said.

Ensuring transparency

To make sure the response process is repeatable, Brian recommended documenting all policies and procedures. “Transparency is important… It’s very easy to get caught in heat of moment in a breach, but then afterwards, can you recall what happened?”

Data breach notification also brings suppliers under its umbrella since many organisations now outsource their data hosting to third parties. “If your data is in a data centre or with a hosting provider, do you have an agreement in place so that they will let you know if they have had a breach? That’s a new thing to worry about. You may have to report a breach because one of your suppliers has had a breach,” Brian said.

Alerting mechanisms are vital because they can provide the information a response team needs to react appropriately to a breach. The 72-hour reporting window means that you don’t need detailed forensic analysis to start with. That can happen at a later stage. Teams should identify tools or software they will need both to detect possible breaches and to manage the response process. Brian suggested using examples like last year’s Equifax breach as the scenario for a desktop exercise to practice breach response. “If your vulnerability scanner didn’t work, how would you act? Use it as a learning mechanism,” he said.

People power

Staff training can also strengthen an organisation’s ability to spot potential breaches as well as responding to them. Brian referred to the Verizon Data Breach Investigations Report which found that many breaches come to light not via tools but through people noticing something strange. “The number one detection tool we have is our staff,” he said.

The last reason for implementing a breach response plan is simply reputation management. “It’s not that you’ve had a security breach that will damage your brand, it’s how well you respond,” Brian concluded.

The post Using ISO 27001 to guide your GDPR breach response plan appeared first on BH Consulting.