Security in your supply chain matters!

Its often said that you are only as secure as your weakest link. In most cases this weak link is described as your end users. But in more cases an often forgotten risk is the weak link in your supply chain. Third party vendors and providers must be reviewed as part of your security management strategy.

The best example of this is one of the first lessons of a web application penetration tester (or a malicious hacker) is to identify how many websites are being hosted on the same server as their target. Once they have this list they can go through each to identify the site with the weakest security and use that to attempt to gain access to the hosting server.

For other third parties who may have a VPN tunnel established with your corporate network; without adequate consideration and controls put in place to manage this access any compromise of your third parties network also compromises your network. Similarly any of your third parties staff, without appropriate controls in place, could damage your organisation.

The solution is to never assume security when dealing with third parties. Where possible several steps should be taken;

  • Security requirements should be detailed in contracts and compliance monitored.
  • Access to the organisations network should be managed, segmented and monitored to ensure only authorized actions are taking place.
  • Only reputable third parties should be contracted.
  • At a minimum all internal security policies, process, guidelines and standards should be applied to all third parties.

What does ISO27001 say?

Security category – 15.1. Information security in supplier relationships

15.1.1. Information security policy for supplier relationships.

Rules should be in place that govern what a vendor can access and how they should access it, as well as specifying other security requirements. These should require the security a vendor should have on their own network, how incidents should be reported and any other requirements your organization deems necessary, depending on the value of what the vendor will have access to. Having a policy outlining what is expected can help guide us when we are considering vendor relationships.

15.1.2. Addressing security within supplier agreements.

The rules we set out in our Information Security Policy for Supplier Agreements should be included in all contracts with vendors and they should commit to upholding these requirements. Periodic auditing can be considered to ensure compliance.

15.1.3. Information and communication technology supply chain.

It stands to reason that if there is access allowed between your network and your vendors network, then any party with access to your vendors network potentially has access to your organization, such as your vendors suppliers. There should be policies in place to ensure access between you and your vendor is restricted and controls to protect against unauthorized access. Ensuring your organization and your vendor keep an audit and log trail to track access and requests can provide accountability and requiring your vendor to screen their suppliers can also reduce this risk.

Security category – 15.2. Supplier service delivery management

15.2.1. Monitoring and review of supplier services.

This will provide us with the confidence that are suppliers are adhering to the security requirements of their contract. Reviewing the audit trail of a vendor, conducting vulnerability assessments on their network and engaging in regular meetings to ensure the vendor understands their obligations can all prove helpful.

15.2.2. Managing changes to supplier services.

Vendors should not be able to make any ad-hoc changes to their service. This can include patching, upgrades and improvements. Any changes should be managed to limit disruption and ensure service continuity in the event of problems occurring. This also gives us a chance to review our security posture and introduce new controls as required to ensure the changes do not weaken our security position.

The importance of masking test data

We discussed in a previous blog post that you should maintain one or more test environments for your applications. This allows us to fully test an application for functionality and security without impacting the production environment. However if these test environments use unsanitised or anonymised production data, which can include personally identifiable information, there is an inherent risk of a data breach.

Organisations should maintain test data, which maps to the productions data for fields, data types and syntax but does not contain actual information on your customers. If you do decide to use production data you must ensure it is santitised, replace any PII in the data such as names, credit card information or similar with tokens, placeholders or randomised segments. There is a good pdf on data masking here; https://www.informatica.com/downloads/6993_data_sec_sap_wp_web.pdf

So what does ISO27001 say;

Security category – 14.3. Test data

14.3.1. Protection of test data.

Any data used for testing purposes should be taken from a carefully selected sample pool and given adequate protection. Avoiding the use of PII and sensitive data can help reduce the risks of disclosure. Standard best practices include mimicking the access controls for production environment on the testing environment, having a procedure for gaining authorization to use production data, maintaining an audit trail and ensuring the destruction of data when no longer needed.

What is needed to ensure a secure software development framework?

Most developers will understand at least one development model, from the Software Delivery Life Cycle to the Waterfall model and many more aside, it is only recently that these models have been reviewed to ensure security requirements are taken into account at the earliest possible stage. This is an important update as new software development, and updates to existing applications can introduce new and evermore nasty vulnerabilities into our network. So how do we reduce our risk in this area? By taking a comprehensive view of security at all stages and taking all aspects of new software development into account!

Security category – 14.2. Security in development and support processes

14.2.1. Secure development policy.

A policy should outline the security requirements required during information systems development. It should include controls to protect the development environment, guidelines on how to create secure code and testing the code to verify it is secure. There are many programming methodologies that can be incorporated into this control such as the Secure Software Development Lifecycle.

14.2.2. System change control procedures.

This control ties into having a change management process and requires a similar process for deploying code during the development stage of new applications. It should include a risk analyse of impact, a roll back plan, testing and approval requirements. Documentation should be updated to accommodate changes and a version control record and audit log maintained. This is SOFTWARE FOCUSED.

14.2.3. Technical review of applications after operating platform changes.

Change always makes information systems more vulnerable. Therefore, we have a test environment but even with that whenever we make changes to applications, we should run through application use cases and conduct tests to ensure the change hasn’t negatively impacted usability or functionality.

14.2.4. Restrictions to changes to software packages

Where possible we should avoid making changes to software packages. Changes can introduce new vulnerabilities, break functionality and may prove a resource intensive exercise. In some circumstances it is justifiable to take this risk for a business need. In these cases, we should make sure we have the vendors written consent to changes, document if the vendor will still support the software and make sure we run comprehensive vulnerability tests to help us assess the risk. It is also best practise to maintain a version repository of any changes made, including keeping a copy of the original.

14.2.5. Secure system engineering principles.


Principles, such as those described in NIST SP 800-160 should be formally implemented into the organizations methodology and process, documented and maintained to allow for secure software engineering throughout the software development lifecycle. These principles should also be reviewed annually to ensure they still represent current best practises.

14.2.6. Secure development environment.

The people, technology and development process should all be protected with consideration given to the classification of data to be processed, the business criticality, legal requirements, access control and backup requirements.

14.2.7. Outsourced development.

With globalization resulting in more and more companies entering into partnership with outsourcing firms for their software development it becomes ever more important that the organizations security requirements are adhered to by their outsourcing partner. To ensure this is the case the company should actively work with and monitor the outsourced team to ensure compliance. Agreements should be in place to ensure the acceptance testing requirements are in place to include security concerns and that periodic auditing of the partners environment allowed.

14.2.8. System security testing.

As security should be a concern at every stage of the project security testing should be conducted throughout development with the extent of testing dependent on the business criticality of the application.

14.2.9. System acceptance testing.

As previously stated “If it doesn’t work securely, it doesn’t work”. There should be clearly documented acceptance criteria for new applications, upgrades and patches that must be met before these changes are accepted and rolled out. These criteria should include security concerns and after testing any issues should be remediated.

What should we look at when defining our security requirements?

We have talked a lot in this blog about various aspects of implementing your information security management system; But one of the most fundamental aspects to this is understanding your security requirements. By taking an objective view of your particular organization we can clearly define what our risk is, what mitigating controls can be put in place and have the best view into our threat landscape. ISO 27001 outlines 3 main considerations to take with this;

Security category – 14.1. Security requirements of information systems

14.1.1. Information security requirements analysis and specification.

Security should be an integral part of the development and acquisition of all new information systems. This means including any security needs as deliverables/requirements at the earliest possible point in development or acquisition. The tenet of “If it doesn’t work securely, it doesn’t work.”[1] should apply when planning, developing, testing and deploying applications. The level of security should be a reflection of the value of the information being processed by the new application and its business criticality.

14.1.2. Securing application services on public networks.

Whenever our information processing takes place across public networks, such as the internet, we need to take steps to ensure the data isn’t disclosed or modified and to ensure there is a level of non-repudiation. Using encryption such as transporting the data over a VPN, SSL/TLS or IPSec can provide us with protection against disclosures and making use of encrypted hashes (known as digital signatures) can provide us with a level of assurance that the information has not been modified. In a PKI setup, we can also achieve non-repudiation through the use of public-private key pairs.

14.1.3. Protecting application service transactions

Special consideration should be given to information involved in transactions where data is modified within the service. Clearly defined stored procedures, database locking and other methods should be used to mitigate against this threat.


[1] Kelly Henderhan

Secure information at all times, especially when transmitting it.

Information is rarely static, staying in one place throughout its lifecycle. More commonly information is processed, disseminated and dispersed, between applications and between people. Processes and procedures need to be created to govern this transfer in a secure and responsible way; likewise personnel (including third parties receiving information) must be trained to treat any information they have access to, apparently.

Security category – 13.2. Information transfer

13.2.1. Information transfer policies and procedures.

The process that employees need to follow should be explicitly stated including an acceptable use policy which employee’s need to sign to transmit information. These policies should include measures to prevent staff from forwarding malicious mail, engaging in harassment and should detail the retention period and disposal procedure for emails, when encryption should be used and steps to protect against information disclosure such as being overheard having confidential conversations in public places.

13.2.2. Agreements on information transfer.

Where feasible during communications with vendors, government and other parties it should be explicitly required in agreed contracts what level of security is required for correspondence. This should keep include non-repudiation, responsibilities in the event of disclosure, technical requirements and data classification.

13.2.3. Electronic messaging.

As more and more companies use Electronic Messaging, such as email, Lync and Slack, in their day to day communications repertoire, and sometimes as a complete replacement for letters and calls, it is important that we have policies in place detailing how this can be used and what controls are in place to protect us such as keeping a record of messages exchanged, ensuring encryption in transit and at reset and having mechanisms for non-repudiation in place.

13.2.4. Confidentiality or non-disclosure agreements.

Staff, contractors and other third parties working in your organization may all have access to confidential information. This needs to be protected and one of the best ways to do this is to require all parties with access to sign confidentiality or non-disclosure agreements(NDA). These agreements should specify what is to be kept confidential, for how long, what the penalties are for disclosure, what the protected information can be used for and how that information should be protected and disclosures reported.

A short post following a long break.

Apologies everyone for the long delay between posts but I hope you enjoyed the last two on network security, and especially Vulnerability Management(which was our most popular posting to date!). Now that the holidays are over and I have settled into my new role lets continue running through the second half on the ISO27001:2013 controls.

This post will be shorter than the previous ones as we are only dealing with one control;

Security category – 12.7. Information systems audit considerations

12.7.1. Information systems audit considerations.

Any audit of information systems should be carefully planned, and have coverage agreed on in advance with the goal of minimizing disruption to business operations. While audits are an amazing tool for finding gaps and weaknesses in our security standing. Auditors are observers. The audit should not change any of the information stored on assets being reviewed and the auditors access should be monitored and logged.

Ideally the auditor should have read only access and should only run their audit scripts outside of business hours to minimize disruption.

Networked security

Your internal network has to be a prominent consideration when planning your information security. Your network carries sensitive data and is the primary route an attacker uses to navigate between your assets. Due to this it should receive special considerations and security should be designed into it from the beginning. This blog post is aimed at covering the 27001 standard but network security has its own separate standard i would highly recommend reading details on how to build controls around your network security. Segmentation, access controls, encryption, detection and more are just some of the tools we use.

Security category – 13.1. Network security management

13.1.1. Network controls.

Your network is how your staff and users access your information systems. That same network, if not adequately protected can allow a malicious user to try and compromise your environment, or if an asset is already compromised to more easily move around. There are many ways to protect your network and the level of protection should depend on your environment. Access should be restricted and controlled to protect against misuse and abuse. ISO 27033 discusses network security in detailed and should be reviewed in relation to this control category.

13.1.2. Security of network services

In addition to segmenting you network you should include additional controls such as firewalls to control access, NAC’s and filtering to restrict access to approved users/devices and NIDS and NIPS to monitor for abuse. Other tools can be used and should any service contracts your company enters into should include requirements for protection levels.

13.1.3. Segregation in networks.

All organizations can benefit from network segmentation. This could be something as simple as

Your network should be divided into subsections based on the users, application type and classification of data held in that environment. There are many ways the segment the network such as using VLANs or firewalls and time should be spent to plan out this segregation to ensure optimal protection and separation.