Monday, 25 July 2016

Amazon phishing scheme

Amazon phishing scheme

In this morning's email were a couple from Amazon, all but one where legitimate. The one that caught my eye was one of those that is "Too good to be true" style phishing attempts.

It was offering a chance of winning £650 of Amazon gift cards.

It has all the classic warning signs of a scam

Below I have run through some simple checks on the email and the originating domain.

The email headers below show the originating server

Return-Path: <>
Delivered-To: ************@*****.*****
Received: from************ (unknown [***.1.150.142])
by mail.************ (Postfix) with ESMTP id 7C5385610F20
for <***********@*****.*****>; Mon, 25 Jul 2016 08:55:10 +0100 (BST)
Received: from************ (************ [***.207.220.216])
by************ (Postfix) with ESMTP id 6E6EC82BE83
for <************@*****.*****>; Mon, 25 Jul 2016 08:55:10 +0100 (BST)
Received: from (unknown [])
by************ (Postfix) with ESMTP id EBA392379B8
for <************@*****.*****>; Mon, 25 Jul 2016 08:55:09 +0100 (BST)
From: "Prime Shop" <>
To: "************@*****.*****" <************@*****.*****>
Message-ID: <>
Date: Mon, 25 Jul 2016 00:55:09 -0700
Subject: Please claim your Amazon Prime shopping credit
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

The domain is registered in Panama as shown below

P.O. BOX 0823-03411

The email server is based in Netherlands


An interesting point is the time stamp on the email shows a 7 hour time difference where as the Netherlands are a hour ahead and Panama 5 hours behind UTC

Whilst none of this is really informative, it is hopefully interesting enough to help people be aware of the risk from emails.

Saturday, 2 July 2016

Surviving the turmoil of brexit (surviving the cybercriminals attack)

In the wake of the Brexit vote and the result for the leave campaign they has been an explosion in news reports on the UK and world economy and how companies and the markets are reacting to the vote decision along with stories of racism and harassment of individuals.

As with any news worthy event; and this is ranking at the top end of such events; the ‘proper’ media along with social media has exploded with stories and headlines capturing the eye of the individual. The result is that for the cyber-criminal there is a wealth of material to use to convincing individuals to fall for malware laden emails, drive by downloads and other attacks and both the individual and the employer is at increased risk of loss due to cyber-attack.

The material that is being generated as a result of the Brexit vote is being used as a hook to engage the individuals with the attack and what normally would be considered outlandish and ignored is now being responded to.

Attacks such as
  •  Pretexting, pretextual, blagging
  • Phishing, whaling, spear phishing, IVR and phone phishing
  •  Baiting
  • Quid pro quo
  •  419, Nigerian scams, advance fee scams

Can all be made more believable by referencing stories from or purported to be from the fallout of the Brexit vote. How many of your employees would look at an email reporting to continue information on the relocation of corporate headquarters to another European capital, or would individuals fall for news on the banking struggling to meet foreign currency demands or having sufficient funds to cover cash withdrawals.

Any such emails, news site, social media article could be well meaning or be part of a cyber-attack. Organisations and individuals can protect themselves by ensuring their or they employees are aware of the types of attacks and the risks from them.

For the organisation they should establish security frameworks of trust aimed at the employee/personnel level (i.e., specify and train personnel when/where/why/how on how social engineering attacks should be handled).

These frameworks should cover
  •  Identifying how social engineering attacks are committed
  • The type of headlines and information used to make them believable; focusing on current affairs.
  • The incident response procedures for handling such attacks, especially if they think they fell for an attack

The employees should be trained in the security frameworks, the frameworks should be tested through a strategy of both announced and unannounced, periodic tests of the security framework and the framework should be continuously reviewed as no solutions to information integrity are perfect.

Sunday, 26 June 2016


Just a quick update to say that I'm going to be more active in maintain this log and update the projects I have been working on and also launching some new interesting projects.

Keep an eye out for my blogs on building pen testing tools into a USB charger.

Saturday, 2 April 2016

Increasing size of RAID1 on a Win7 system

Increasing size of RAID1 system drive on a Windows7 machine using a hardware raid (Intel Rapid Storage Technology) built by a Microsoft Deployment Toolkit (MDT) deployment

A stumbling block is the BDEDrive which is placed immediately after the system drive by the MDT tool; ideally this partition should be the first on the drive to save problems like this.

The BDEDrive is used by BitLocker, if you are using BitLocker then there are some additional steps to follow which are outlined at the end of this article. If you are not using BitLocker then you can delete the BDE drive as outlined in the main body of the article,

You can enter the Intel® Rapid Storage Technology option ROM by pressing Ctrl and i when prompted during POST.

Increase size of RAID1

  1. Turn off the system and remove one of the hard drives.
  2. Replace it with one of the large hard drives, ideally port 1 leaving the smaller drive on port 0
  3. Turn on the machine and ensure the RAID is set to rebuild in the diagnostic screen during POST
  4. Once booted into windows, use the Intel® Rapid Storage Technology user interface to monitor rebuild progress
  5. Once rebuilt, turn off the system and change the remaining small disk, ideally swap the large drive from port 1 to port 0 replacing the small drive and add the new large drive to port 1
  6. Turn on the machine and ensure the RAID is set to rebuild in the diagnostic screen during POST
  7. Once booted into windows, use the Intel® Rapid Storage Technology user interface to monitor rebuild progress

Deleting the BDEDrive

Before the BDEDrive can be deleted the system needs to be configured using BCDboot to replace the boot mechanism used by BDEDrive whether or not BitLocker has been enabled or not.
 BCDboot copies a small set of boot-environment files from the installed Windows image to the system partition. Next, BCDboot creates a Boot Configuration Data (BCD) store on the system partition that instructs the computer to boot to the Windows partition.

Use BCDboot tool from the command line
  • bcdboot c:\windows /s c:
You now need to make the c: active using diskpart tool.
  • diskpart
  • select disk 0
  • select part 0
  • active
Then you can delete the BDEdrive partition either using the disk management console or using diskpart.
  • diskpart
  • select disk 0
  • select part 1
  • delete partition
Reboot into windows, windows will see the smaller drive size unitl the RAID is reconfigured, using the Intel RST tool to increase the size of the existing RAID array.

Once the RAID array has been increased; progress of which can be monitored in the Intel RST tool.

Reboot into windows and using the disk management snap in increase the size of the C: drive

Do a final reboot of windows to ensure all changes have been completed successfully

What to do if you need to use BitLocker

  1. Temporarily disable BitLocker and decrypt the C: drive. Applying the chkdisk /f as required until all error are fixed.
  2. Follow the instructions in the main body of the article until you expand the C: drive, if you need to use BitLocker you will need to leave space at the end of the drive for the partition to be created; leave at least 300MB, preferably around 500MB of space when expanding the C: drive
  3. Once the system has completed its final reboot and confirmed the new size of the C: drive
  4. Re-enable BitLocker which will create a new BDEDrive partition and ask you to save the recovery key.

Saturday, 3 October 2015

CISSP Software Engineering

The 2015 changes to the CISSP common body of knowledge saw the official book discuss the differences between 'Software Engineering' and more 'Traditional Engineering' in the Security Assessment & Testing domain. As part of the explanation of this I developed the following infogram that shows differences.

Sunday, 6 September 2015

CISSP v2015

The CISSP certification went through a significant change in April 2015 and was updated and restructured. It now consists of 8 domains and I have started looking at the contents of the new CISSP certification which has 40% new material in it.

Here are the mind-maps that I have generated of the new domains.

The new 8 Domain CISSP

Domain 1: Security and risk management

Domain 2: Asset security

Domain 3: Security Engineering

Domain 4: Comms and network security

Domain 5: ID and access management

Domain 6: Security Assessment

Domain 7: Security operations

Domain 8: Software development
I will be looking at the content of each domain in future posts

Sunday, 31 May 2015

PCI DSS and SSL/TLS certificates

This article is aimed at those implementing the PCI DSS v3.1 requirements and those conducting audits to ensure an organisation is compliant. It aims to provide some background around the issues, how encryption is incorporated with the standard and how it can be audited.

The Payment Card Industry (PCI) Security Standard Council (SSC) require merchants and service providers to use industry standards and best practices for strong cryptography and secure protocols. The PCI SSC glossary defines strong cryptography as follows:-

Cryptography based on industry-tested and accepted algorithms, along with strong key lengths (minimum 112-bits of effective key strength) and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). At the time of publication, examples of industry-tested and accepted standards and algorithms for minimum encryption strength include AES (128 bits and higher), TDES (minimum triple-length keys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (2048 bits and higher).

They also refer to NIST documents on guidance on cryptographic key strengths and algorithms. A CISSP certified professional should be aware that cryptographic algorithms have a life-cycle; new stronger algorithms are introduced where the strength relates to the work factor and time need to break or brute force the keys for the algorithms. However, the strength of the cryptographic algorithms weakens with time as Moore’s law and other advances in computing reduce the work factor and time need to break or brute force the keys. Every cryptographic algorithm can be broken if the keys can be derived.

With recent vulnerabilities in SSL and TLS along with vulnerabilities in RC4, the PCI SSC has upped the boundary where strong cryptography can be considered to start. With PCI DSS v3.1 it has removed SSL and early TLS from new implementations and for existing implementation they must be removed by June 30th, 2016. For POS POI devices and the SSL/TLS endpoints, this can be done as long as they can be verified as not being susceptible to SSL/TLS exploits. For existing implementations using SSL and early TLS there must be a formal Risk Mitigation and Migration Plan in place. The PCI SSC have published guidance on migrating from SSL and Early TLS.

Versions of SSL & TLS

SSL v1
Netscape Proprietary protocol
Not published
SSL v2
Netscape Proprietary protocol
Published Feb 1995
SSL v2
Netscape Proprietary protocol
Published 1996
TLS v1.0
IETF Standard (RFC 2246)
Jan 1999
TLS v1.1
IETF Standard (RFC 4346)
Apr 2006
TLS v1.2
IETF Standard (RFC 5246)
Aug 2008
TLS v1.3
IETF Standard
Draft April 2015

The use of RC4 in all versions of TLS is prohibited by RFC 7465 due to attacks on the algorithm that weaken or break it. RFC 7465 is an Internet Engineering Taskforce document published in Feb 2015, which outlines the changes to TLS that should be implemented to remove the use of RC4.

In additional to the 3 requirements listed in the guidance notes from the PCI SSC (highlighted in grey below) there are some additional requirements that involve strong cryptography in the PCI DSS.

PCI DSS v3.1 requirement
Requirement 1.1.6
Documentation and business justification for use of all services, protocols, and ports allowed, including documentation of security features implemented for those protocols considered to be insecure
Requirement 2.2.3
Implement additional security features for any required services, protocols, or daemons that are considered to be insecure.
Requirement 2.3
Encrypt all non-console administrative access using strong cryptography.
Requirement 4.1
Use strong cryptography and security protocols to safeguard sensitive cardholders data during transmission over open, public network
Requirement 8.2.1
Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components.

For existing implementations of SSL and early TLS when be audited they would need to include the usage under insecure protocols in requirement 1.1.6 and include a business justification for its usage.

If SSL and early TLS is being used, it should be configured to reduce the risk of being exploited and these additional measures should be covered under requirement 2.2.3

For requirement 2.3 and 2.4 strong TLS should be used, if SSL and early TLS is used they should be a risk mitigation and migration plan in place and the SSL and early TLS should be replaced by 30th June 2016.

Requirement 8.2.1 again strong TLS should be used if not similar controls to those for requirement 2.3 and 2.4 should be in place.

Testing the connection

If a HTTPS based connection is used than the strength of the connection can be determined through a browser. Browser’s these days present security information about the connections, although different browsers do it different ways. With Firefox it is easier to determine the encryption strength as shown in the screenshot below.

With Internet explorer using the menu and file properties the encryption properties of the currently selected tab can be viewed. Additionally the server certificate can be viewed, along with the trust chain.

If you examining the validity period of the Google certificate, you will notice it is only valid between May 6th, 2015 and Aug 4th 2015. Whilst this is a short period it demonstrates a point that security professionals and cryptologists understand is that the more frequent a key is used the increased chances of statistically analysis determining something useful about the key, which will help with break it. With hybrid cryptographic systems such as TLS and SSH, they use the public/private asymmetric encryption to dynamically generate a symmetric secret key for encrypting the data stream used to protect the information exchanged.

The PCI DSS standard v3.1 has a number of requirements involving the life-cycle of cryptographic keys and these will apply to digital certificates as well as any other form of encryption. 

PCI DSS v3.1 requirement
Requirement 3.5
Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse
Requirement 3.5.2
Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) in a secure manner at all times
Requirement 3.5.3
Store cryptographic keys in the fewest possible locations.
Requirement 3.6
Fully document and implement all key-management processes and procedures for cryptographic keys used for encryption of cardholder data, including the following
Requirement 3.6.1
Generation of strong cryptographic keys
Requirement 3.6.2
Secure cryptographic key distribution
Requirement 3.6.3
Secure cryptographic key storage
Requirement 3.6.4
Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines
Requirement 3.6.5
Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key component), or keys are suspected of being compromised.
Requirement 3.6.6
If manual clear-text cryptographic key-management operations are used, these operations must be managed using split knowledge and dual control.
Requirement 3.6.7
Prevention of unauthorized substitution of cryptographic keys.
Requirement 3.6.8
Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities.

To cover the requirements listed above there will need to be suitable policies, procedures, standards, baselines and guidelines in place.

The cryptoperiod for a site with extremely high levels of traffic will have a shorter validity period than one with minimal amount of traffic. NIST produce a guideline on cryptoperiod which is mentioned in the PCI DSS standard.

Certificates can have a defined key usage field that defines the activities the certificate can be used for; it could indicate that the key should be used for signatures but not for encipherment. The correct certificate must in place on the server.

VeriSign and other bodies use classes of certificates to determine the level of authentication they use to verify the identity of the organisation requesting the certificate.
  • Class 1 for individuals, intended for email.
  • Class 2 for organizations, for which proof of identity is required.
  • Class 3 for servers and software signing, for which independent verification and checking of identity and authority is done by the issuing certificate authority.
  • Class 4 for online business transactions between companies.
  • Class 5 for private organizations or governmental security.
Checking for class 1 is done by simply checking if the requester responds to the email address the certificate is for, this level of checking is not suitable for an ecommerce operation.

Certificates need to be trusted by a recognised certification authority (CA), self-signed certifications, or certification issued by untrustworthy CA should not be used. A certificate trust chain should lead to a certificate from a CA that is recognised by a computer without installing a certificate for the CA.

Within the EU there is an EU Directive 1999/93/EC on "a Community framework for electronic signatures" which defines the term qualified certificate and the requirements an issuer must meet to issue such a certificate.

There are a lots of documents describing best practice for digital or X.509 certificates that are either vendor or platform dependent. The recommendation is to find the relevant best practice for the platform and infrastructure you are operating.

In addition to examining a certificate using the tools within browsers it is possible to download the certificate and use tools such as openSSL to display all the fields of the certificate. The following command is an example of how to output the certificate in a readable form. The certificate will need to be in a suitable form such as .pem or 64base encoded .cer if exported through windows operating system.

OpenSSL> x509 -in google.cer -noout -text

In addition to the certificates installed, a server will support a range of cipher suites that support various combinations of encryption algorithms and key lengths to exchange keys, protect data streams, and provide integrity, non-repudiation functionality.

There are a number of naming conventions in use for cipher suites, the most common format is that based on openSSL naming convention that defines the encryption for the four basic functions of a cipher suite.
  • key exchange,
  • server certificate authentication,
  • stream/block cipher
  • message authentication
An example of this would be DHE-RSA-AES256-SHA which breaks down to the following.
  • DHE for key exchange, 
  • RSA for server certificate authentication, 
  • 256-bit key AES for the stream cipher, and 
  • SHA for the message authentication.
For PCI DSS compliance the server should only support cipher/key length combination considered to be strong for it to meet the requirements.

When clients connect to servers as part of the negotiation they decide on which ciphers to use and exchange keys. The cipher has to be common on both devices and as an organisation operate a server they generally don’t control of what is installed on clients and have a range of ciphers installed.

As a cryptologist/security professional should understand the negotiation does not go for the strongest cipher as there is considerable computational overhead in strong ciphers and long key lengths but often selects the weakest common denominator. Therefore to force strong cryptography the server should only have strong ciphers installed.

Tools such as Nessus, sslscan, ssltest can list the installed cipher suites and ssltest (operated by Qualys SSL Labs) can give a rating to the security of the server certificate and installed ciphers.

Scanning tools can determine the set-up of SSL/TLS and the features that have been enabled, the exposure to currently known vulnerabilities, the installed ciphers and the preferred ciphers. The output of the tools does need to be interpreted by security professionals who understand cryptography.

Additional testing

For compliance testing there is a need to demonstrate that strong cryptography which renders all authentication credentials (such as passwords/phrases) and card data unreadable during transmission is proved.

As requirement is to ensure that secure channel is created before the information is exchanged the definitive method will be to use a packet sniffer and look at the communication session being created and ensure a secure channel was created and the data is not being transmitted in cleartest.
In order not to affect either the server or client and ensure that the transmitted packets are being monitored, a network tap or the span or mirrored port on a switch can be used to monitor the communication as shown.

The packet sniffer is isolated from the endpoints, it can’t give a false positive by reading packets before they have been encrypted which is a possibility if the packet sniffing software was installed on an endpoint.

The network tap or switch configured to span or mirror a port can be used to monitor the traffic between endpoints, the packet sniffer will pick up all traffic passing over the monitored connection and will need filtering to remove the frames and packets not relevant to the testing.
Using tools such as tcpdump, wireshark and network forensic analysis tools can help an auditor to accurately determine in the connection and the date being transferred is securely encrypted.


SSL Server Test is a free online service operated by Qualys SSL Labs that performs a deep analysis of the configuration of any SSL web server on the public Internet.

The OpenSSL Project is a collaborative effort to develop a robust, commercial-grade, full-featured, and Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS) protocols

SSLScan queries SSL services, such as HTTPS, in order to determine the ciphers that are supported. SSLScan is designed to be easy, lean and fast. The output includes preferred ciphers of the SSL service, the certificate and is in Text and XML formats.

tcpdump, a powerful command-line packet analyzer; and libpcap, a portable C/C++ library for network traffic capture.

Wireshark is a network protocol analyzer for Unix and Windows.

Sunday, 10 May 2015

Root Servers

When discussing networking and how the internet works as part of some of the courses I deliver the topic of DNS comes up as a security risk. A question asked is whether the root servers could be taken offline by a DDoS attack. There have been attempts at doing this and the two most notables ones are:-

October 21, 2002

On October 21, 2002 an attack lasting for approximately one hour was targeted at all 13 DNS root name servers. The attackers sent many ICMP pings using a botnet to each of the servers. However, because the servers were protected by packet filters which were configured to block all ICMP pings, they did not sustain much damage and there was little to no impact on Internet users.

February 6, 2007

On February 6, 2007 an attack began at 10 AM UTC and lasted twenty-four hours. At least two of the root servers (G-ROOT and L-ROOT) reportedly "suffered badly" while two others (F-ROOT and M-ROOT) "experienced heavy traffic". The latter two servers largely contained the damage by distributing requests to other root server instances with anycast addressing. ICANN published a formal analysis shortly after the event

A DDoS attack may of been possible in the early days of the internet however the resilience and security that have been put in place since then would make it unlikely, unless the biggest ever attack ever seen on the internet was conducted

Root servers resolve the top level domains (TLD) such as .uk, .com or .xxx and are critical to the operation of DNS. According to the Root Server Technical Operations Site there are 13 critical servers with multiple instances of each server using anycast addressing to distribute them around the world.

Root Server Operater Instances
A Verisign, Inc. 5
B Information Sciences Institute 1
C Cogent Communications 8
D University of Maryland 69
E NASA Ames Research Center 12
F Internet Systems Consortium, Inc. 58
G U.S. DOD Network Information Center 6
H U.S. Army Research Lab 2
I Netnod 49
J Verisign, Inc. 81
M WIDE Project 7
13 Servers 12 Operators 465 Instances

Location of root servers worldwide

Sunday, 15 March 2015

Shadow IT: Centralised vs distributed IT Management

Historical when computers were first introduced into a company it was through individual departments, typically Finance and they purchased their own computer systems. As the usage of computers grew and IT become first a support function and then a core part of the business. The structure of organisations changed with as they introduced an IT department which managed IT and ensured commonality across the whole of the organisation. The governance of IT become centralised within the IT department.

IT Governance is a subset of corporate governance, focused on information and the technology and the performance and risk management around the handling of information and the technology. It is how organisations align their IT strategy with business mission, ensuring they stay on track to achieve their strategies and goals. 

The use of IT has continued to mature throughout organisations and IT has become a platform or service on top of which the functions of the company are built. If you examine an organisation today there is a core platform of servers, workstations and networks which underpin the finance systems, sales, marketing, production and other activities. Each of these activities has different requirements and expertise. IT decision on spending is becoming dispersed throughout organisations, according to a survey conducted by BT of 1,000 IT "decision-makers". This has been backed by research by Garner which estimates by 2020, 35% of organisations’ technology budget will be spent outside the IT department.

This is creating “shadow IT”, and has been given impetus by the growth of consumer technology and cloud computing, which make it increasingly easy to deploy technology without going through the corporate IT department. With businesses under pressure to innovative, flexible and adaptive it has been realised they can often deploy solutions more rapidly by bypassing the IT department. BT’s study showed nearly three-quarters of respondents say they are more concerned about security with the move to a more distributed approach to IT. The various departments are very keen to purchase and deploy IT based solutions however they don’t want to support them or take responsibility for them working and are happy for central IT to provide this function.

Ensuring that shadow IT is subject to proper governance is a challenging task for CIOs. Part of the solution is by supporting the business in meeting its objectives by liaising with all parts of the business. They are the experts on what they need; they need support on ensuring the requirements can be met within the corporate governance framework. Shadow IT should not be considered a problem but should be adopted as part of a distributed IT function.

Friday, 13 March 2015

Shadow IT – what are the risks?

Increasingly within organisations a shadow organisation is building up and will threaten the security of the overall organisation. This is not the mafia or a criminal sub culture, but an alternative to the organisations IT department.

Citizen Programmers + Rogue Devices + BYOD + Tech Savvy Employees = Shadow IT

Increasing, as the workforce becomes more tech savvy as the millennium generation are starting to become predominant as employees. Each department has its own group of geeks that the rest of the department turn to as first line of support. I have seen this everywhere I have worked, people like myself are asked questions or asked to fix things as we are immediately available and often understand IT and the business function and give advice quicker and trusted more than IT support who can live up to the reputation of the IT Crowd and associated with the phase “Turn it off and turn it on again”

In the 21st century business are increasingly facing employees who are “citizen programmers” where they have developed their own applications with macro programming languages in a lot of business software to manipulate raw data and draw useful information and reports. Citizen programmers can generate applications that become mission critical in the way they draw useful information from the organisation’s data. These applications are outside the control of IT and often not known to those doing the BC&DR activities.

The tech savvy employees and often those less technical aware are bring consumer technology into the office either as part of BYOD or often as rogue devices that IT and the organisation know nothing about. These can introduce a range of attack vectors that the organisation may not be aware of and unable to put appropriate controls in. I have seen employees set-up Google remote desktop to allow remote access to their workstation so they can be more productive out of the office and IT have not been aware of this remote access channel.

So what are the risks of this shadow IT within your organisation?

  • No governance of the activities
  • Lack of security awareness and alignment with business mission
  • Increased risk of data leakage
  • Increased attack surface area
  • Dependence on unknown and uncontrolled applications

What can be done, IT like cyber security needs to be aligned with the business needs and this requires better integration with the end users to ensure they can do their jobs in a secure manner that does not affect productivity, allow initiative and innovation but does not impact on security which is the triad of confidentiality, the integrity and availability of assets.