Systems Development and Security
In this bite size awareness article I shall look at systems development from the security perspective. I shall leave the specifics of the software development life cycle and software testing to a later article.
This article is a high level view of what you need to know when procuring new information systems and software.
Any new application or system must meet the operational needs of users while at the same time fitting with the security architecture of the organisation. Consequently, the security requirements must form part of the overall system specification.
No new application should be acquired without a fully documented security requirements specification (SRS). The SRS contents will be guided by the organisation’s security architecture. Therefore, it is essential that the information security team is involved in the system design at all stages especially early during requirements capture.
To keep overall system life costs affordable it is important to capture all requirements as early in the development life cycle as possible. As with any other aspect of development, assurance controls identified and introduced at the design stage are significantly cheaper to implement and maintain than those added during or after implementation.
Above all else the organisation must ensure any system meets all of their Confidentiality, Integrity and Availability requirements.
Statements of business requirements for new systems, or enhancements to existing systems, should specify the requirements for security controls. Such specifications should consider the physical, procedural and technical controls to be included in the design.
Security requirements and controls should reflect the business value of the information assets involved, and the potential business damage that could result from the absence of security. Consequently, risk assessment and risk management steer the analysis of the security requirements and help identify the assurance controls to fulfil them.
controls identified and introduced at the design stage are significantly cheaper to implement and maintain than those added during or after implementation
Therefore, the process to be adopted would be along these lines:
- Write functional requirements;
- Identify assets involved;
- Classify assets by value (Both tangible and intangible Eg Brand);
- Identify potential threats (Who could gain access?);
- Perform risk assessment (What damage could they do?);
- Identify required controls (How will assets be protected?);
- Build Security Requirements Statement.
When drafting the SRS it is important to consider all aspects of the system security. Therefore, the SRS will cover both the application software requirements and any associated clerical procedures to be implemented.
Buy It In or Develop it in-house?
When a new application is required the organisation must decide whether to buy a ready made solution (Commercial of the shelf – COTS) or develop a bespoke solution.
In addition to the usual project issues of schedule, available skills and cost, security should also be a deciding factor. Therefore, it should be included within the whole decision process of whether to buy COTS or follow the bespoke route.
No new application should be acquired, by any route, without a fully documented requirements specification. The requirements specification should either include, or have attached, a SRS. Equipped with the full requirements specification the organisation can review the products available in the marketplace to see if they meet the requirements for both functionality and security.
If the organisation decides to build a bespoke system, rather than buy COTS, it might choose to use a specialist software systems development company to produce the application. This may be a preferable route to systems development rather than keeping the skills within the organisation. Unless the organisation develops many bespoke systems, or has a particularly rigorous specification for a large application, it is unlikely an in-house development team would prove cost effective.
If systems development is outsourced care must be taken to ensure that the third-party is properly controlled. In this case appropriate contracts are key to a successful project outcome.
Of great importance is the determination of the ownership of the resulting system which must be clearly and unequivocally defined from the outset.
Whichever system procurement route the organisation adopts it must ensure thorough testing is completed, particularly regarding security.
Many of us buy a used car at some point in our lives. When we do so we make certain checks before parting with our cash.
- Is the car mechanically sound?
- Can the seller demonstrate the vehicle has been properly maintained?
- Can the seller prove the car is theirs to sell?
Similar care must be taken in purchasing software systems.
As part of the COTS product assessment process vendors must prove their software or service is robust and reliable. The purchaser needs assurance that the system meets all of their security requirements.
The purchaser should insist the application vendor provides proof that they’ve included security in their quality assurance testing.
In particular, the following elements, amongst others, should be considered within the requirements, and the product assessment:
Input Data Validation
Data input to application systems should be validated to ensure that it is correct and appropriate;
Checks should be applied for out-of-range values, invalid characters, missing data, buffer overflows, etc.
Controls on Internal Processing
Controls will depend on the nature of the application, but could include :
Balancing controls (closing balance versus opening balance and transaction values);
Validation of internally generated data;
Hash checks on records and files.
This is a technique used to detect un-authorised changes to, or corruption of, the contents of a transmitted message. It should be considered for applications where there is a requirement to protect the integrity of message content; for example in electronic funds transfer.
A buyer’s task in assessing the suitability of a COTS system can be eased through formal certification. Such certification proves to the buyer that certain security criteria are met by the system ‘out of the box’.
ISO/IEC 15408 – Common Criteria is such a certification system.
ISO/IEC 15408 is intended to:
- Provide a common structure and language for expressing products and systems security requirements;
- By establishing a common criteria base, the results of a security evaluation will be meaningful to a larger audience.
ISO/IEC 15408 is a set of harmonised evaluation criteria effectively bring together several evaluation standards to simplify the mutual recognition of evaluation results.
The aim of the Common Criteria evaluation is to test a product’s claims for the protection of Confidentiality, Integrity and Availability of the system.
The Common Criteria evaluation results are expressed in the form of assurance packages.
Currently there are seven assurance packages called Evaluation Assurance Levels that increase in rigour and formality from EAL1 to EAL7. These are designed to confirm:
- The correctness of implementation;
- The effectiveness in satisfying objectives;
- The product is built well and meets its objectives; that is, does what it says on the box.
Products are evaluated against the relevant criteria by a Commercial Licenced Evaluation Facility.
You can imagine that such evaluations are very expensive and we have to wonder whether a developer would see a worthwhile return on their investment. Certainly, if an organisation was to specify an EAL7 product they could rest assured it is going to be extremely, may be prohibitively, expensive!
There are other evaluation schemes available that seek to reduce the costs involved. For example, the CESG Assisted Products Scheme (CAPS) and the CESG Claims Tested Mark (CCTM). These less exhaustive evaluations speed up the process, reduce the costs involved, but still give a recognised level of assurance about a product’s claims for security design.
So, certification is a good indicator of the security of a product, but be sure that the product specification is what you need.
You could end up paying for more security than you require! Or you might not get what you expected:
“Microsoft made a big deal about Windows NT getting a C2 security rating. They were much less forthcoming with the fact that this rating only applied if the computer was not attached to a network and had no network card, and had its floppy drive epoxied shut, and was running on a Compaq 386. Solaris’s C2 rating was just as silly.” Bruce Schneier
If the product specification does not match your needs, then you must consider in-house or outsourced development.
Comprehensive details about various certifications and Common Criteria in particular can be found on the CESG website.
Buying Systems – Some Final Thoughts
When buying systems there a couple of areas to consider in addition to those outlined above.
To ensure the purchased software is secure, the following should be considered:
- Buy applications only from reputable sources;
- Use evaluated products;
- Buy applications in source code so that it can be verified;
- Inspect all source code before operational use.
Are there restrictions on changes?
Generally, modifications to software packages should be discouraged. However, if it is essential to modify a software package (perhaps to include more security to meet your requirements), the following should be considered:
- Should the consent of the vendor be obtained? (Consider licence restrictions, configuration issues)
- Will the vendor make the change as a standard product update? (Unless the wider customer base would benefit the vendor is unlikely to make a one-off update.)
- Will the organisation now become responsible for the maintenance of the software on an on-going basis? (Consider the contractual issues if you make changes or the vendor updates the application on your behalf.)
The organisation must take all reasonable steps to ensure that any product it purchases meets its security requirements.
Controlling Outsourced Development
These days, few organisations can afford to keep software development skills in-house. It is often more cost effective to use third-party developers when they need new bespoke software.
If your organisation outsources development there are a number of issues that should be addressed.
- Who owns the intellectual property rights (IPR) to the end product software?
- If it remains with the developer, what are the licensing arrangements?
Have you ever read the shrink wrapped software licence for any application you have purchased? You might be surprised at the conditions vendors place on your use of their product!
Disputes over IPR and ownership can have unforeseen and major widespread consequences as described in this Quartz article regarding a small piece of code that proved to be quite critical to the Internet.
Rights to Audit
Insist on the right of access to audit the development processes and procedures.
Quality of Work
Ask for a third-party security assessment of the finished code.
Software escrow means the deposit of the software’s source code into an account held by a third party escrow agent. The agent acts as trusted third party and will offer specialist services for escrow.
Escrow is typically requested by a party licensing software, the licensee, to ensure maintenance of the software.
The software source code is released from escrow to the licensee if the licensor files for bankruptcy or otherwise fails to maintain and update the software as promised in the software license agreement.
This is an essential precaution where the business is dependent on third-party software. There are several companies which specialise in escrow facilities.
Test and Production Environments
Whether software has been developed in-house or by a third-party, it is important to thoroughly test it, not only to ensure it performs correctly from a functional point of view, but also to check its security.
Because of the potentially destructive nature of testing, it should never be carried out in the live production environment.
The consequences of running untested code in a live environment can be catastrophic as 123-reg discovered recently.
A Development and Test environment can be set up to reflect whatever production environment is required in order to test software before it is deployed in the live or production environment.
The following points must be considered in a development and test environment:
- Test data should be protected and controlled, and kept separate from the live data.
- The use of databases containing personal information should be avoided. If such information is used, it should be depersonalised before use.
- The access control procedures, which apply to operational application systems, should also apply to test application systems.
- There should be separate authorisation each time operational data is copied to the test system.
- Operational data should be securely erased from the test system as soon as testing is complete.
- The copying and use of operational data should be logged to provide an audit trail.
I shall look at software testing in more detail in another article.
Management often views information security as an overhead rather than a business enabler. For example, if bonuses are paid to middle managers for reducing departmental spending then information security might seem an easy area in which to save costs..
Certainly, information security will always involve compromises between competing objectives like cost, ease-of-use and time-to-market with a new product.
Without strong motivational systems that support compliance with information security requirements, competing objectives will outweigh what little management support there is for information security.
One example of a mechanism that encourages information security compliance is the required sign-off from an Accreditor for all procured software systems.
Security accreditation is the formal authorisation by the accredited official (the Accreditor) for system operation and the explicit acceptance of risk. It usually follows a review of the system including its management, operational and technical controls, and involves a risk assessment.
If the controls on a new, or significantly modified, application do not meet the Accreditor’s minimum control criteria, he can withhold his signature. Without his signature, a new application cannot be moved into production. Developers, and management, are likely to take security more seriously knowing there is a possibility that this signature will be withheld.
Accreditors are commonly found in central government, law enforcement and the military. They are responsible for ensuring any new system, or changes to an existing system, are of the required standard.
Other organisations where Accreditors are appointed include financial and aviation organisations. You will find an Accreditor in any organisation where information security is a priority matter.
In order to minimise the corruption of systems, there should be strict control over the implementation of all changes.
Formal change control procedures should be enforced, ensuring that:
- Security and control procedures are not compromised;
- Support staff are only given access to those parts of the system necessary to do their work;
- Formal agreement and approval is obtained before any change is made.
A change control procedure should include:
- Ensuring changes are submitted by authorised users (system owners);
- Reviewing control and integrity procedures to ensure they will not be compromised;
- Identification of all affected entities (hardware, software, information, etc.);
- Formal approval of detailed proposals before work commences;
- Maintenance of version control;
- Maintenance of appropriate documentation;
- Maintenance of an audit trail.
These procedures should apply to all changes whether prompted by a business requirement or as a result of software changes promoted by the software vendors.
Why do systems still suffer security issues?
So if system developers and organisations adhere to the guidance and best practice highlighted in this article for systems development, information security problems should go away, shouldn’t they?
Clearly not as we still experience security issues with our systems as witnessed by incidents such as the TalkTalk hack. This breach was reportedly caused by a SQL Injection attack. This is a well known vulnerability which should not find its way into a modern system if best practice is followed.
But, consider the complexity of modern systems and it is no surprise that some vulnerabilities creep in to the final design. As we shall see in a later article software system testing is not a trivial matter.
There is no substitute for getting the security requirements right at the start of any project if a developer is to stand a chance of avoiding vulnerabilities in their code. Investing time and effort from the outset of any development project could save £Millions later. Whether any compromises are made along the way to the final design and product is a risk-based decision to made by the organisation’s accreditation authority.
Finally, one thing is certain, technology alone will not secure our information. That is why the SRS must include all assurance controls including manual and administrative.
If it is possible for a human to make an error that adversely impacts on Confidentiality, Integrity and Availability, then that error will occur at some point.