Always keep the law in mind when planning security.

Your legal and contractual requirements should be firm considerations when planning out and implementing your information security. If in doubt as to what your obligations are and which pieces of legislation apply to you, work with your legal team to identify them.

Security category – 18.1. Compliance with legal and contractual requirements

18.1.1. Identification of applicable legislation and contractual requirements.

All companies should adhere to their contractual and regulatory obligations, but to do so we need to know what those obligations are. Your organization should take care to go through its contracts and understand what is expected of you. You should also have specially trained staff with knowledge of regulations impacting your industry at hand when drafting policies, procedures or stands. These staff can keep you informed of changing requirements so you can be sure to include them to ensure you are compliant. Remember, if you have offices in multiple legal jurisdictions your plans should take the different legal environments into account.

18.1.2. Intellectual property rights.

You should make sure that, for any material you use such as software, you are compliant with copyright and IP laws, as well as any licensing fees that may apply. Ensuring that software on your assets has been attained from the vendor, and that only correctly licensed versions can be installed we can reduce our risk. Outlining employee responsibilities, such as not using pirated software, in the Acceptable Use Policy can help us be compliant, as can regular audits of software. Be prepared to hand licensing information to the vendor should they wish to audit you.

18.1.3. Protection of records.

In many jurisdictions there is legislation in place to specify how record retention should be carried out. An example of this from the GDPR is for healthcare records[1];

“In general, medical records should be retained by practices for as long as is deemed necessary to provide treatment for the individual concerned or for the meeting of medico-legal and other professional requirements. At the very least, it is recommended that individual patient medical records be retained for a minimum of eight years from the date of last contact or for any period prescribed by law. (In the case of children’s records, the period of eight years begins from the time they reach the age of 18).”

 You should have policies in place to protect records in accordance these laws, as well as contractual and regulatory requirements. Similarly, you may wish to tailor your retention policy in a manner that benefits your organization and helps further your business needs. This can be done but should be carried out in line with legislation, regulatory and contractual requirements. Keeping records for too long, beyond a reasonable need for the business can cost resource in maintaining them and we run the risk of greater loss should a breach occur, with that in mind it is encouraged to limit the retention period of records where reasonable.

18.1.4. Privacy and protection of personally identifiable information.

Nearly all countries have some requirements for reasonable protection of collected PII. In some jurisdictions, such as the European Union and the incoming GDPR, not sufficiently protecting PII can cause fines to be leveraged against the organization. To use the GDPR as an example a company can be fined up to 4% of its annual revenue. One of the best ways to best ensure compliance is to designate an employee a Privacy Officer who can advise on local regulations.

18.1.5. Regulation on cryptographic controls.

In a previous control we discussed the importance of using encryption for confidentiality, integrity and non-repudiation, but in some states the use of encryption is heavily regulated, and in some cases, require decryption keys to be provided to the authorities. It is important to understand your local laws when using encryption or incorporating encryption in your products.


[1] https://www.icgp.ie/go/in_the_practice/it_faqs/managing_information/8E2ED4EE-19B9-E185-837C1729B105E4D9.html

There has been a breach! How do we manage Incidents?

Even with a comprehensive defense in-depth architecture, highly qualified and trained staff, the right processes and a plethora of technical security controls in place we are all at risk of a security breach. How we react to this breach and how we learn from it is vital to ensuring we continually improve our posture.

Incident response is a very flexible area because how much you invest in it should, generally, be in proportion to your organisations risk. NIST has a great, if heavy, guide on this located here – https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final but for understanding the framework steps themselves I much prefared Rapid7’s summary; https://blog.rapid7.com/2017/01/11/introduction-to-incident-response-life-cycle-of-nist-sp-800-61/

ISO27001 however focus’ on 7 controls;

Security category – 16.1. Management of information security incidents and improvements

16.1.1. Responsibilities and procedures.

Any security incident that could take place should have procedures in place to instruct staff how to act with responsibilities and roles clearly defined. This should cover all phase of an attack[1];

  1. Preparation
  2. Identification
  3. Containment
  4. Eradication
  5. Recovery
  6. Lessons Learned

Actions at all stages should have procedures in place, actions taken at each step should be logged and reviewed and, where necessary it should be possible to escalate incidents. When creating procedures creating a list of potential incidents should be considered.

16.1.2. Reporting information security events.

Your organization should document what constitutes a security event and the should have a single point of contact the should receive reports of these incidents. This point of contact can be a person but is more likely an Incident Response team. All staff should know who to contact in the event of an incident and should have a standardized process to lodge reports.

16.1.3. Reporting information security weaknesses.

Giving staff training to help them identify security weaknesses, and having an easy to use reporting process to report their finding can greatly assist your security team with identify problems. Part of this training should discourage employees from trying to test or exploit the weakness they have found as this should be done by specially trained personnel only.

16.1.4. Assessment and decision on information security events.

An information security event indicates that the security of an information system, service, or network may have been breached or compromised. It indicates that an information security policy may have been violated or a safeguard may have failed. An information security incident is made up of one or more unwanted or unexpected information security events that could very likely compromise the security of information and weaken or impair business operations.[2] Trying to decide if an event constitutes an incident is an important function of the point of contact but they may not work in isolation and the responsibility my fall on a dedicated Information Security Incident Response Team.

16.1.5. Response to information security incidents.

The intent behind the response is to prevent further compromising of the environment by containing the attacker. While the most obvious way of doing this can be shutting down the impacted servers it should be noted that in doing that we lose evidence stored on the machines RAM. Evidence collection should go hand in hand with the initial response and the assets affected should have an image of their hard drive taken and hashed and a chain of custody kept of who handles the original asset’s data. Any testing or investigations should be done on copied images, never the original. Documented procedures should guide your team on how to correctly respond, who is to be notified and how evidence is to be collected and what the escalation process is.

16.1.6. Learning from information security incidents.

The documentation on the incident that the organization has accrued and the experience its incident response team has gained should be used to digest how the incident was responded to with the intent on finding ways to improve the process. This can help us speed up incident resolution in future, or avoid them completely. In some cases, past incidents can be used for training new incident response staff and for improving organizational awareness.

16.1.7. Collection of evidence.

Evidence collection is vital if your organization plans to pursue charges and having specialist staff with training on how to properly collect evidence and store it is vital to ensuring the evidence can be admitted to court. ISO/ IEC 27037 goes into detail on evidence collection and should be read and documented procedures written. Staff should then receive training on those procedures and only those trained staff should be involved with evidence collection.


[1] http://blog.securitymetrics.com/2017/03/6-phases-incident-response-plan.html

[2] http://www.praxiom.com/iso-27001-definitions.htm

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.