Home » Posts tagged 'Standards'
Tag Archives: Standards
Big Data and AI
I have the pleasure of working on Advisory Group for CSP2017, the 2017 Cyber Security Practitioners Conference – The Annual York Cyber Security Conference (last year). As such, I get chance to talk with Colin Williamson, the driving force behind the conference, on a regular basis. We have a similar view that as Professionals, we should not be worrying about what is happening today, but what is likely to impact businesses over the next few years. Forewarned and Forearmed.
One recent conversation related to Big Data and Artificial Intelligence.
If you have a self-learning system being used with a large data set to make automatic decisions as part of a business process, then who is liable for the judgements that this AI makes? For example, if it acts in an illegal discriminatory way towards groups of individuals.
- Is it the developer of the AI system?
- Is it those that set the Learning System its objectives?
- Is it the owner of the Big Data set that it has been taught with?
- Is it the company blindly acting on the AI’s conclusions? (“The AI’s Employer.”)
- Is it a particular individual that the AI is acting on behalf of? (“The AI’s line manager.”)
Clarifying the responsibility for Information, and the ownership of the business process that the information upfront, and understanding the risks of using that Information in this way, will save a lot of difficulty, and the cost of legal fees and possible penalties, later on.
Of course, such a system starts to produce challenges for “traditional” IT security methods and controls:
- Inadvertent data leakage – can repeated questioning of an AI give an insight into the Data it was trained on?
- How do you train and test an AI in a test environment without using real data sets? Is synthetic data good enough for the potentially subtle relationships the AI will see?
- How do you define a test for an AI system to demonstrate correct processing?
- How do you validate that the AI is continuing to function correctly and appropriately?
At the moment, standards for Information Management for Artificial Intelligence’s are rather thin on the ground(!).
The conversation with Colin was fascinating because it dealt the AI systems themselves having their own legal existence and rights – something that lawyers are beginning to seriously discuss.
Updates to Password Standards
Password best practice is changing. Two of the important governmental standards bodies, CESG in the UK and NIST in the US have issued, or are about to issue new guidance.
The CESG Guidance is now published, and makes a series of “tips” for managing and designing password systems.
The NIST Guidance is in draft format and is more prescriptive in it’s requirements. The SHALLs and MAYs are here, but the context and reasoning is important and worth understanding.
Both revisions are focused on making Passwords usable for people and have the following characteristics:
- Length is more important than convolution. The days of “must include numbers, letters, mixed cases, and four symbols from the DaVinci Code” have gone. However, all characters should be permitted within the passwords. Longer passwords (upto 64 characters in the case of NIST) should be possible.
- Passwords proposed by the user should be checked against a Blacklist and matches rejected. There is no recommended blacklist, however using available password dictionaries may be a good start.
- Allow the use of password management tools: allow users to paste passwords into the entry fields.
- No default passwords. No sharing of passwords between users.
- Limit the rate at which users can attempt to log in, rather than the number of attempts. This reduces the possibility of brute-forcing an account, but reduces the number of account lockouts requiring an account reset – a form of Denial of Service. Combine this with threat detection based on seeing multiple failed login attempts by a user, reporting it and acting on it.
- Store passwords properly. You never store passwords, only store suitably salted, stretched and hashed value for the key.
ISO27001 Mandatory Documents
The update from ISO27001:2005 to ISO27001:2013 changed the requirements in two key areas: Documents required and in the Security Management process. I will deal with the management process in a later posting.
The original six documents still apply and are absolutely needed for any ISMS. An Auditor will expect to see these before the audit, and will normally enquire about them during an audit.
- Scope of the ISMS (clause 4.3)
- Information security policy and objectives (clauses 5.2 and 6.2)
- Risk assessment and risk treatment methodology (clause 6.1.2)
- Statement of Applicability (clause 6.1.3 d)
- Risk treatment plan (clauses 6.1.3 e and 6.2)
- Risk assessment report (clause 8.2)
However, ISP27001:2013 has tightened up its expectations of the documentation needed to support the security control implementations. As these are within the Security Controls Annex (Annex A), and thus subject to the Statement of Applicability, it may be the case that these are not implemented as there is no identified risk requiring them. Again, an Auditor may ask for them prior to an audit, either expressly, or more commonly as “Can you send me all your security documents please?”. These expected Documents in Annex A are:
- Definition of security roles and responsibilities (clauses A.7.1.2 and A.13.2.4)
- Inventory of assets (clause A.8.1.1)
- Acceptable use of assets (clause A.8.1.3)
- Access control policy (clause A.9.1.1)
- Operating procedures for IT management (clause A.12.1.1)
- Secure system engineering principles (clause A.14.2.5)
- Supplier security policy (clause A.15.1.1)
- Incident management procedure (clause A.16.1.5)
- Business continuity procedures (clause A.17.1.2)
- Statutory, regulatory, and contractual requirements (clause A.18.1.1)
Additionally, specific security records are required to be kept:
- Records of training, skills, experience and qualifications (clause 7.2)
- Monitoring and measurement results (clause 9.1)
- Internal audit program (clause 9.2)
- Results of internal audits (clause 9.2)
- Results of the management review (clause 9.3)
- Results of corrective actions (clause 10.1)
- Logs of user activities, exceptions, and security events (clauses A.12.4.1 and A.12.4.3) – again depending on the Statement of Applicability requiring these controls.
There is no mandated expectation of how long these records should be kept, however there should be a policy defining what that is, and the period should be long enough to make record keeping useful. For example, two or three review cycles would be a reasonable period to keep audit reports for.
Cloud Security
The Cloud is Someone else’s Computer: a Service accessed over the Internet, but technically still a client accessing data held on a shared server. The only differences are in the commercial arrangements, and in the sharing of the service by different unrelated customers with potentially different expectations.
The ownership of the data, and their responsibilities do not change.
Cloud Security Standards
While the principles of ISO27001 apply to any security management regime, there are several specific areas of concern as the information that is the responsibility of customer is now being held and processed in its entirety by a third party supplier outside of the customer’s normal security arrangements.
There is no single recommended security framework specifically for the management of cloud services, however the principles of ISO27001:2013 (and 2005 before it) along with the best practice in ISO27002 and ISO27017, form a sound basis for approaching all information security including Cloud Service provision.
Ideally, the Cloud Service provider should have some form of independent accreditation or certification of their service by a third party that has audited their security arrangements. The scope of this certification should be checked to ensure it covers the service being offered.
Certification will be against one of the pre-existing standards, such as ISO27001, or against one of the emerging standards such as that being developed by the Cloud Security Alliance. Where card and payment details are being handled, then compliance to PCI-DSS v3 would be expected as well.
As a quick reference, the UK Government’s Guidance is to be recommended.
