SecureSDCL (Software Development Life Cycle)

Evaluating security at the end of the development cycle, prior to launch, is inefficient. By the time the application has been deployed fixing the issues is dramatically more expensive and time consuming.  It is vital that security is baked into the product before the developers have even started to code.  By implementing a SecureSDLC (Secure Development Life Cycle), security issues can be considered, evaluated and resolved when it is cheap and simple to do so. 

CNS can help by providing security experts to mentor and if necessary run the SDLC.  Our testers have all developed applications and understand both the technology and the business constraints.  The SDLC Service can range from occasional briefings to attending every weekly meeting for a project, to ensure security issues are resolved before they become problematic.  

The process starts with definitions and designed to ensure that end to end security is baked into all products and service offered by customers of these services. The services are a combination of proven methodology, technical excellence, sound process and cutting edge ingenuity. 

1. Security Definitions

CNS Hut 3 will conduct an exercise initially, and then every six months, to create, define and publish the clients Security Definitions. This will be a high level document that defines the high value data and systems, the level of protection and the security principles that should be followed within the client.  This will not be an abstract and isolated exercise; it will take input from a number of sources:

Analysis Of Security Incidents - CNS Hut3 will conduct an analysis of all known security incidents both internally and externally against the client.  This will indicate areas where controls do not exist, have failed or have been badly implemented.  In addition it will offer indications of the areas of interest for attackers.

Analysis of Previous Testing - Using the results of all previous pen-tests (performed by CNS Hut 3 and any other relevant parties). All technical vulnerabilities will be extracted and the root causes will, where possible, be identified (e.g. badly defined input fields). This is an extremely valuable evaluation of the security posture of the institution and will, through statistical analysis, identify where security is good and where it is bad.

The Client - As an external party, CNS Hut3 can offer valuable insight particularly using our knowledge of other institutions, however the most important opinion is that of Client. Ultimately it is the client that will have to accept or reject risk.  CNS Hut3 will analyse the opinion of key stake holders and general staff and refine these opinions and existing documentation into a defined desirable security stance.  This is vital to help strike the correct balance between security, functionality, flexibility and the rapid expansion of the institution.

Regulatory -  Many of our clients operate in a highly regulated markets.  In addition to these, other bodies and legislation need to be considered, such as the Data Protection Act and Regulatory Investigatory Powers Act.  CNS Hut3 will, using our knowledge of these regulations and our direct contacts into the relevant bodies, extract and refine the security requirements and objectives that the authorities expect to be implemented.  It is important to note that in some cases these regulations are vague and very much subject to interpretation.  It is vital that the client is seen to be following not only the explicit requirements but the spirit and objectives of the requirements.

Best Practice - A large number of published standards exists and provide a useful starting point for the institution. However, simply following the standards will not solve the security problem. In some cases standards will weaken security. CNS Hut3 will, using our in-depth knowledge of these standards, along with direct contact into the bodies publishing the standards, identify and refine the requirements, helping the client to be secure and if relevant obtain compliance and certification with the standards.

Market & Threat Landscape Intelligence -  Client is a small but rapidly growing institution. Whilst it might not currently be under sustained target attacks (though there is some evidence that this is happening from the CNS Hut3 Phishing protection service), it is reasonable to presume that as the Client grows, both in size and reputation, it will be targeted. To help the institution remain a step ahead of this, CNS Hut3 will analyse the attacks, patterns and frauds affecting the industry utilising our links with Government agencies and the financial industry as a whole.

2. Technical Security Standard

At the moment the developers, network team and project managers, either internal or outsourced, do not have a full understanding of what security means. It is such a subjective term that will never be met. To resolve this CNS Hut3 will produce a highly technical and detailed Technical Security Standard. It is expected this will be a very large document that will constantly involve. To produce this CNS Hut3 will involve all the relevant third parties.  This will include details such as:

Input validation - All variables passed should be treated with suspicion as if they are an attack vector. They should be filtered and checked to ensure that only the expected values are accepted (Internet banking, Mobile, APIs, 3rd Party interfaces with other institutions). All other values should be blocked at client side, WAF, server side, backend. This multi layered approach to security which works on the presumption that only one of these layers needs to be successful will reduce risk and set expectations for the developers. If developers produce code that does not comply with the standard it will be reject as not fit for purpose.

Detailed methods on how to block and reject attacks -  Rather than simply relying on programmers to know this and to develop accordingly, CNS Hut3 will work with them to define the methods that should be used to block attacks, these can be evaluate in detail and used across the estate, rather than reinventing the wheel badly each time.

Training

Simply producing standards documents has little impact. It is vital that they are read, understood, implemented and where necessary updated. CNS Hut3 will run multiple training courses for multiple different groups and types of individual to ensure all parties are aware of the standard and how to implement it, as well as raising the general security awareness. CNS Hut3 training will be interactive, fun and short, long dry classroom based courses simply do not work for anything other than passing exams. It is envisaged that the following training courses will be run and available.

Secure Coding Training - Rather than simply telling programmers to program securely and how, CNS Hut3 will demonstrate it but most importantly demonstrate why it is important. For example, rather than saying that any input fields associated with the customer ID should be 8 Digits long and accept only numbers, CNS Hut3 will deploy our Pen Test Training Rig and get the developers to attack (without assistance) a badly configured application to demonstrate why it is important and how it works, then patches can be applied and the attack repeated.  The objective is to make sure the developers understand the risk, how to test it, why it’s important and how to remove it.

Secure Commissioning - If project managers don’t ask for security and define it, they will not get something.  Rather than security being seen as a gate it should be seen as functionality; if the application is not secure it does not work. CNS Hut 3 will run interactive courses to help educate project managers about security risks and help them understand the security specification. This will be achieved through pen testing workshops to demonstrate what the vulnerability means and why it is important, this will be on a custom training rig that is relevant to the sector.

General Security Awareness - If security is to be built into all areas of the Client, then the full institution needs to be aware of it.  For example a teller is more likely to be socially engineered than the developers. To help combat this, CNS Hut3 will run fun, interactive training course for all members of the Client.  It is recommended that groups should be small and a mixture of different jobs and levels. This will cover areas such as Phishing, social engineering, hacking, physical security and be a fun, straight forward and interactive course. The intention of this training is to make looking after customer data a part of  Client’s amazing customer service, not a barrier to it.

 All training courses will include feedback, if candidates are struggling to understand something in the standard then it can be reworded or adjusted, equally training will be adjusted and updated by the results of testing and code review, if issues keep occurring then clearly developers or project managers do not understand the requirement and that area needs focus in training.

Project Security Design

Security must be a feature; as such it is vital that it is part of the design process.  Building security in during the design phase is simple and cheap, but adding it in later is disruptive, time consuming and more expensive.  CNS Hut 3 will attend all project meetings and is happy to attend at short notice.  CNS will advise on security, pose security questions and offer guidance on preventing issues. This will be a table top exercise, based on ensuring all designs meet the Technical Security Standard and Security Definitions from the design phase.

Design Review

Once a design is finalised, all relevant material will be packaged up and as part of the internal  Client design commissioning process, CNS Hut3 will conduct an independent design review with a formal sign off process. The objective is to sign off the design as being compliant with the security requirements, and if any risks exist they are documented for acceptance or treatment by the Client.

Should the design not meet the required standard it will be passed back to the project team for updates.

Development

CNS Hut3 will be available to the developers on demand to offer guidance relating to the security of the code they are developing.  A ticketing system will be provided to allow them to log request for guidance and receive a response as long as direct access to Pen Testers with development experience who are familiar with the Clients environment.  The objective is that rather than guessing, developers can ask and clarify.

Code Review

Once developers have produced code and accepted it internally, the code will be provided to CNS Hut3 for review.  CNS Hut3 will conduct a review using a mixture of static code analysis tools and manual inspection.  The objective being to identify coding errors that can create security risks as well as any breaches in the defined policies.

Should the code not pass this stage it will be pushed back into a design review and then code updates until it is resolved.

Penetration Testing

Once code has been deployed and functionality tested, CNS Hut3 will conduct independent testing of the application.  This will be based on four requirements:

Attack Testing - As an attacker with credentials would attack, CNS Hut3 will attempt to compromise the environment using any method possible.

Scenario Based Testing - CNS Hut3 will test specifically agreed scenarios to identify risk, for example - can a user add a payee to another users account?  The scenarios will be based on the documentation above, the change log, the design review and input from the client.

Compliance Testing - CNS Hut 3 will test to ensure that the application or environment has been developed in--line with the Clients security standards.

External Vulnerability Assessment – Once live CNS Hut3 will scan the application for vulnerabilities regularly against the most up to date vulnerability databases.

All of the above will produce formal PDF Reports, a CSV of issues, and a master risk register or all issues across all hosts and tests will be updated and maintained by CNS Hut3.

Risk Identification & Register

CNS Hut3 will maintain (based on Code Review, Penetration Testing, Design Review and incidents) a register of risks.  This will be a frequently updated document allowing for the remediation of issues, the acceptance of issues as well as statistical analysis to identify risks that are repeated, failures in coding or training etc, these can then be fed back into training and documentation.

Scenario & Risk Mapping

To the non-technical members of the Client, who often are responsible for accepting risk, a list of separate individual risks is of little value.  CNS will create detailed, real-life risk scenarios to help the institution understand the risks and identify which issues need to be fixed.  For example:

Individual risks of poor session management and cross sit code injection can be combined.  If an attacker was able to send a spoofed link to a user who then clicked on the link, they would be able to hijack the users session.  This means that they would be able to gain access to the victim’s client account and remove funds without a username and password.