Steve's Security Blog | @northvein

Why it's a good idea There are a myriad of reasons to test in peace time, the controls and processes which collectively represent your incident readiness. These include: Validating your Incident Readiness - testing can confirm that you are as ready as you think you are, and that nothing has changed resulting in an end state which prevents you from initiating IR.  Assess Controls Coverage and Identify Gaps - testing can confirm your controls coverage is adequate as well as highlighting those gaps which you'd rather not have in the event of a real issue. Demonstrate value of investment - you've probably spent a lot of time and other people's money acquiring controls, attracting talent and preparing for the eventually of an incident. Internal stakeholders will likely already be looking for assurance that their investment has been worth while.  Demonstrate investment and commitment to interested parties - internal stakeholders considered, you'll lik

My mate Dan set up our bug bounty programme and wrote a post over at the company  engineering blog about it back in November. It’s a solid guide to establishing your own with practical considerations for outlining such a programme, getting it off the ground, running it, rendering the benefits to your organisation and extending its coverage and scope over time. It’s been a triumph and as we approach month 4 I wanted to spend a bit of time outlining some things worth considering before starting your own programme. I also wanted to dig into some of the points of friction we’ve encountered. Before You Start (Day 0)  First things first… Is a Bug Bounty Programme right for you? If this is new to you and you’ve not already got your own programme up and running, it’s worth stopping to check that starting your own is right for you and your business. Do you have the right people -or- the right people with enough time? Your programme is going to need feeding

Over the course of this week various news outlets began to report and further investigate issues with Intel’s Atom C2xx chips. These low power CPUs appear to suffer from a hardware fault which renders them useless after roughly eighteen (18) months of service. You should care because this family of CPUs is widely used across network platforms and peripherals. Effected product lines include security platforms (Cisco ASA, pfSense Netgate), Switching platforms (Cisco Nexus, Broadcom Trident II), industrial routing components (Cisco 809) and possibly Network Storage. The list of products will likely only grow over time as vendors investigate the issue and report on effected products. What Should You Do Now? Keep Up to Date – you should look to ensure that your engineering and infrastructure people are aware of this issue and are monitoring the situation for updates. Identify your risks – with the information available now and as more information is released, look to i

A friend outside infosec and GRC recently asked me to provide him with a high level overview and introduction to GDPR. He’d been engaged in watercooler discussions about the approaching changes to data protection and, as a non-security IT professional, wanted a jump start to finding out more about it sensing the need to be informed. The below is what I sent him and includes guidance I’ve received from other security practitioners currently discussing the issue on the local circuit.  Introduction  Essentially, GDPR (general data protection regulation) is a tooled-up revision of the DPA (data protection act), a chunk of law that looks to ensure that personal information is sufficiently protected. The current DPA is based on an EU directive so any backhanded comments you might hear about this all going away ‘cos Brexit are nonsense. Without consistency across Europe (Brexit or not), doing business would be impossible. When does it come into effect?  GDPR comes into e

In December, the PCI Security Standards Council released guidance around scoping and network segmentation for card data environment (CDE) assets. In their own words: “Many organizations struggle to understand where PCI DSS controls are required and which systems need to be protected. This document provides guidance to help organizations identify the systems that, at a minimum, need to be included in scope for PCI DSS. Additionally, the document provides guidance on how segmentation can be used to help reduce the number of systems that require PCI DSS controls.” The guidance goes on to visualise a scoping process, considering each category of system in turn: I believe it’s worth highlighting the ‘broadness’ of the “Connected to OR Security Impacting Systems” . These are cases where the: System component is on a different network (or subnet or VLAN), but can connect to or access the CDE (e.g., via internal network connectivity). System component can connect