Industry:DECC Smart Metering Implementation

Return to Global Industry Committee

Submission Response
Latest first

Final version
tbc

Introduction
This official response has been developed by an open consultation process across UK chapters of the Open Web Application Security Project (OWASP), and has been submitted to DECC by the OWASP Global Industry Committee.

Response
'Request for comments on licence conditions relating to security risk assessments'

''1. Do you consider that the draft licence conditions deliver the policy intention outlined in this document? Please provide comments on where the drafting could be amended or clarified.''

No we do not believe the draft licence conditions deliver the policy intention outlined in this document.

Appendix A paragraph Z.5 defines equipment to include associated software and ancillary devices and provides a definition of "secure" in paragraph Z.6 - the definition of "secure" is not sufficient. In addition to the existing three items, the Supplier En-to-End System is Secure if both the System and each individual element of it is designed and operated to ensure that it is not subject to interference or misuse that:


 * allows any connected communications network to be used for unauthorised purposes
 * allows the collection or processing of unauthorised data by the software
 * results in applications undertaking unauthorised activity
 * gives rise to the presence of unapproved or malicious code within the authorised software
 * allows installation of unapproved software
 * permits use of any part of the system to attack other elements of the System or any other information system

There is also the potential for the risks to smart meters a supplier is aware of to vary. The risk assessment by each supplier should always address a common, centrally maintained, register of known smart meter risks, instead of each supplier developing their own. Each supplier would therefore have to address these in addition to any other organisational, technical, processes or physical risks they deem in scope.

Guidance on assessment of impact in each risk assessment should be provided to ensure that impacts are not solely based upon risks to the suppliers themselves (e.g. loss of license, inability to issue bills, etc). Impacts on individuals (whether customers or not), wider society (e.g. critical infrastructure, availability of assets/power, economy, trust) and other partner organisations should also be addressed.

The proposals do not take into account a need to address any major change to the risk profile that needs to happen in less than six months; for example should a major new threat be identified in smart metering then a risk review should take place within weeks not six months.

2. Do you have any comments on the proposed approach that suppliers should carry out a number of good practice security disciplines and procedures as is set out in this document?

Yes we have additional comments.

Some minimum information security baseline requirements should be mandatory, not simply those based on a risk assessment. These should include:


 * IR 7628, Smart Grid Cyber Security Strategy and Requirements, NIST, Aug. 2010
 * Application Security Verification Standard, OWASP

In particular we recommend that security needs to be built in from an early stage of all development and acquisition processes. There is no guarantee that systems can be made secure very late in the lifecycle when problems are found. Fixes to fundamental design flaws may require months of redesign, retesting, and  redeployment. Even then, there is no requirement for the people, process, and technology used in fixing the findings to be security-qualified. Security controls available at the tail end of the process may not be sufficient or appropriate to mitigate the risks that are found. Finding problems at the very end of the lifecycle is the most expensive (in terms of time and money) to mitigate. If issues are found, suppliers will have to wait for the findings to be mitigated, perform another series of end-to-end tests and security risk  assessments, and then hope that the identified issues were fixed.

The draft conditions does not require those who supply equipment, software, or services in the smart meter ecosystem to demonstrate that they have staff who are qualified to build it securely in the first place. Nor does it address what security processes they might apply during the development of  hardware, software, and services. We recommend these requirements are added.

Testing will be required as part of security lifecycle, and mandating that testing is performed by qualified testers is reasonable. The DECC should ensure that security-qualified staf are involved in the deployment, operation,  and monitoring of smart meter systems. The DECC should mandate that suppliers demonstrate that they retain security-qualified staff. Recognised certifications such as the CISSP (https://www.isc2.org/cissp/), GIAC  (http://www.giac.org/) and similar are appropriate. Likewise, the suppliers should mandate that providers of smart meter hardware, software, and  services should have staff on-hand who are qualified in software security,  so that there is a greater chance that the product include appropriate  security controls and mechanisms. The CSSLP (https://www.isc2.org/csslp/) or GSSP certifications (http://www.giac.org/) are appropriate  certifications to demonstrate security competence in software development.

''3. Do you have any further comments with regard to the issues raised in this document? We also welcome general comments around the approach to small suppliers, the processes expected of suppliers in general, and any related costs.''

Yes we have further comments.

The proposals suggest suppliers should seek to align their security operations with ISO27001. This standard is not available free-of-charge to the public and other interested parties, and we suggest that it should not be cited in any requirements.

Each security risk assessment, information security policy and information security management system should be available for public inspection.

The conditions should be comply with the requirements in Smart Grid Security Recommendations, ENISA, 11 July 2012

About OWASP
to be added in final draft

Return to Global Industry Committee