Tools Update (28th Nov)

My slightly irregular update at the moment on new and updated Information Security tools that I have come across or use. The tools are mainly those for PenTesting although other tools are sometimes included. As a bit of background into how I find these tools, I keep a close watch on twitter and other websites to find updates or new releases, I also search for pen testing and security projects on Source Forge. Some of the best sites I have found for details of new tools and releases are http://www.toolswatch.org/, http://tools.hackerjournals.com/

Nessus 5.0.2 available
http://www.tenable.com/products/nessus/select-your-operating-system
This release is a bugfix only release
Nessus is a vulnerability and configuration assessment product. Nessus features high-speed discovery, configuration auditing, asset profiling, sensitive data discovery, patch management integration, and vulnerability analysis of your security posture.


Wireshark 1.8.4
http://www.wireshark.org/download.html
Wireshark 1.8.4 has been released. Installers for Windows, Mac OS X 10.5.5 and above (Intel and PPC), and source code is now available.

Will be trying to produce this update more regularly in December

Information security align with business needs

Just found a good article on the SC Magazine website about "Game on: Case study with Electronic Arts and Allgress" which discusses challenges around protecting EA network. However there is a quote in the article.

"In today's world, security executives need to be able to align their investments with business goals and be able to show that there is some sort of return – be it risk reduction, business enablement and or financial savings," says Borrero, who previously led security and risk management strategy at Pacific Gas and Electric and served a CISO role at Robert Half International, a global staffing firm.

This quote highlights one of the points I try and get across on security training about information security needs to be aligned with the needs of the business and it must be an enabler not a disabler of the business meeting its mission. It will be a quote I will be point to when I run my next training courses on the CISSP.

PCI DSS

This is a copy of a blog I wrote for IT Governance, where I will be publishing a series of blog entries that will be looking at the PCI DSS and the 12 requirements contained within it; the series is starting by looking at the scoping of the cardholder data.

This is really a general overview of the standard and its requirements.

Compliance with PCI DSS should be considered the minimal level of security that should be implemented and does not ensure that an organisation is secure; however compliance should ensure that an organisation has in place the procedures, policies and work practices that will reduce the possibility of a cardholder data breach and improve the effectiveness of an investigation of a breach. It is important an organisation that is PCI DSS compliant maintains the compliance at all times.

Within the PCI DSS standard it refers to a ‘trusted’ network, which is the environment within which the cardholder’s data is identified as being either processed, stored or transmitted. A key point about the standard and its related standards and guidelines is that they have been written to protect cardholder data as it is processed, stored or transmitted and not necessarily to protect the entire infrastructure of an organisation from all security threats as it is a very specifically focused standard.

For an organisation the best methodology for making the process of implementing and gaining compliance with the PCI DSS standard easier, is to reduce the scope of the implementation, which is the size of the environment involved with cardholder data. This can be achieved by reducing the footprint of cardholder data within your organisation’s environment by analysis of where cardholder data is stored, processed or transmitted and reducing the locations within the environment where it is handled, segregating the cardholder data from the rest of the organisations environment, creating a trusted environment and a non-trusted environment reduces the scope for implementing the standard. In fact if it is possible to completely remove cardholder data from the environment which will make the environment become completely out of scope, however if 3^rd parties are handling cardholder data for you, the responsibility for ensuring they are doing so within the requirements of the standard remains with your organisation.

Any part of an organisation including its infrastructure where cardholder data is processed, stored or transmitted will be within scope and is known as the cardholder data environment (CDE) and is required to be protected (becomes trusted), any part of the organisation and infrastructure that is out of scope and also the public internet is considered untrusted.

The standard looks at the protection between the CDE and the untrusted environment; it covers all aspects of providing that protection, not only technical controls but includes policies about those employees who have access to the cardholder data and the trusted environment as well as measures to help with the investigation of breaches.

In order to identify where cardholder data is within you environment it is necessary to track the flow of data across the infrastructure which requires up to date network documentation and knowledge of the processes within the organisation. Examining the data flow, starting from where it enters your environment, this can be through a gateway from the internet onto the network, via phone lines, the postal system or via fax. Following the movement of the data from its entry point(s) through the organisation until it permanently leaves organisation or is destroyed will identify all the components that are involved in the processing, storage and transmission of the cardholder data.

At this point I like to give a reminder that the systems involved in handling cardholder data not only include the hardware and software of the infrastructure, but everything connected to the CDE and also includes the employees of the organisation who handle the data processing, phone calls, post, fax, maintenance of the infrastructure, administration of servers etc, It will also cover not only your own organisation but any 3^rd party organisations (know as service providers), who may be processing, storing or transmission cardholder data on your behalf or providing a service that effects the processing, storing or transmission cardholder data within your organisation such as an IT support company who have administrator rights to firewalls, routers or servers.

Analysis of the data flow should not only cover the active processing, storage or transmission of cardholder data but include the storage and processing of the backup media that may contain cardholder data including when these are stored off-site.

Upon completion of the analysis of the flow of cardholder data through the organisation, it would be desirable to reduce the scope of the CDE by segregating the environment where the cardholder data is from the rest of the environment and also reducing the number of systems and processes where cardholder data is handled.

In addition to identifying where cardholder data is expected to be, steps should be taken to ensure that cardholder data is not located in places where it is not expected to be, i.e. in a spreadsheet on the desktop of a data analyst who generated a report on a database containing cardholder data. In order to examine the whole environment of an organisation for unknown locations of cardholder data, techniques from e-Discovery can be used to identify the locations of cardholder data, hopefully all the identified locations will match the data flow analysis results, any mismatch shows cardholder data is being held in unidentified locations that are likely not part of the normal data flow.

Conducting a scoping exercise is only part of the story, the documentation of the reasons for identifying the CDE and reducing the scope from covering the whole organisation to a sub-set of the organisation (trusted network) needs to be kept for reference by any auditor. This is typical of the PCI DSS standard in that includes requirements that the documentation of the business reasons for implementing a control or deciding it is not applicable need to be part of the PCI-DSS documentation.

In the following blog entries I will be examining the requirements of the PCI DSS in turn and other issues affecting PCI DSS.

eVoting

Due to the elections in the USA there have been a number of articles about eVoting and the security of voting machines.

It was interesting to see in an article "Internet-based and open source: How e-voting works around the globe" http://arstechnica.com/features/2012/11/internet-based-and-open-source-how-e-voting-is-working-around-the-globe/2/ a comparison of banking and eVoting

"With banking, you want to know—and have an extensive record—of what actions were taken when, and you associate them with a certain person. Voting, however, requires secrecy, and separation from a person and a specific identity. Furthermore, with banking, there is insurance and other precautions put into place to reassure customers against fraud."

The comparison is good, with online banking an audit trial of transactions is important, however for voting there is a need for security and strong authentication, however anonymity is not necessary a requisite for an eVoting system if it is to mirror some of the paper systems.

Within the UK there is security and authentication, although often this is weak, involved in voting but there is no anonymity, a person's identity is tied to their vote. All voting papers in the UK have an unique number that is recorded against the name of the voter when they attend at the polling station, this allows the authorities (with a court order) to trace how an individual voted.