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

When things go wrong – Business Continuity and Redundancy!

Security category – 17.1. Information security continuity

17.1.1. Planning information security continuity.

Having comprehensive business continuity and disaster recovery plans can be vital for in organization’s survival should a disaster occur. Such plans should be sure to include security which is still important, if not more so, during a crisis and should be included in any plans created. If there are no such plans then the organization should strive to maintain security at its normal level during a disaster. If possible Business Impact Analysis’ should be carried out to investigate the security needs during different disasters.

17.1.2. Implementing information security continuity.

Ensuring that security controls in any plans are carried out in a disaster is just as important as having the plans themselves. There should be documented processes and procedures in place and easily accessible to staff during such a situation. These documents should be available in both electronic and paper format, with copies stored in geographically separate locations. This should allow us to maintain a command structure that includes security responsibilities, and keeps staff accountable and aware that security is still necessary. In some types of disasters our primary security controls may fail, in this case we should have separate, mitigating controls ready to be implemented.

17.1.3. Verify, review and evaluate information security continuity

This helps us ensure our plans are effective and will work as intended. In practice, it is carried out through table-top exercises, structured walkthroughs, simulation tests, parallel tests, and full interruption tests.[1] The plan should be updated to reflect changes in the organization, frequently tested to ensure it works as envisioned and that everyone involved is trained to know what to do with a disaster strikes.

Security category – 17.2. Redundancies

17.2.1. Availability of information processing facilities.

A key tenet of security is ensuring availability and this can be better enforced by using redundancy. This is simply having multiple redundant components so that if one fails operations fail-over to the remaining, working components. This can be expensive and what applications are in scope for this redundancy should be in line with the business needs.


[1] https://en.wikipedia.org/wiki/Disaster_recovery_plan#Testing_the_plan

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