It is becoming increasingly apparent and accepted that cyber liability can touch everyone in a project – from end-user to designer to supplier to integrator. No longer can security equipment security and service providers look away and think that it is not their problem. Further, insurance companies look like they are becoming more adept at pricing cyber insurance to the actual risks involved.
I write this column after hosting a discussion on Cyber specification language at our CONSULT 2018 technical security symposium. CSI’s MasterFormat 2016 has added a place in which to specify cybersecurity for electronic safety and security systems; however, creating usable language to be incorporated into a project specification remains a work in progress.
A number of elements need to be nailed down from the outset. For the consultant, this requires an understanding of the client’s current environment. Is there a secure network to begin with? Is there a formal information security program in place?
Depending on the level of the client’s cyber preparedness, a knowledgeable consultant may have the opportunity to improve on the existing situation, or specify something that dovetails with the client’s program. In either case, an up-front conversation is warranted.
Here are some of the elements that might be included in a specification…Cyber elements included in a specification should be reviewed and signed off by the client as satisfactory. Communication with the client and preparing a solid specification represent a good start.
· Asset management – A key element called out in the NIST Cybersecurity Framework is to have a comprehensive inventory of physical devices and systems, software platforms and applications, and external information systems. As each of these may be include in a security installation, such an inventory should be provided to the client.
· Supplied equipment – To what extent has the manufacturer provided for a cyber secure product? Has it been third-party tested and certified for resistance to vulnerabilities? Is it patchable? Can selected protocols and service be disabled? Can it be supervised? Does the manufacturer offer a strong “hardening guide” document? This information should be known to all parties involved in the process.
· Software and applications – In addition to the above, a manufacturer should have well-documented processes and procedures for secure software development and testing, including third-party vulnerability testing.
· Passwords and login credentials – This is certainly one area where security device and application passwords need to be in sync with a client’s existing procedures. If this is not possible, a secure password provisioning strategy should be agreed to at the outset and enforced. It appears that this is simply not the case in many projects, where convenience trumps security.
· Communications – The plan should provide for secure communications throughout, from edge to application. This includes wireless networks, using nothing less than WPA2.
· Rights and privileges – The principle of least privilege provides that only enough access is provisioned to allow a party to complete their assigned task. Administrative rights should be carefully guarded. How are these assigned and verified in the initial system installation and configuration?
· Servers – All servers should be provisioned with the latest operating system patches and updates. Database servers should be separate machines with their own administrative privileges.
· Remote access – The communication channel should be secure and access rights limited.
· Ports – Required ports should be clearly identified by the manufacturer; further, consider requesting a summary of open and closed ports after installation, to be reviewed with the IT Department.
The Integrator’s Angle
From this point, what happens when the project gets into the hands of the integrator? In my mind, question number one is whether the integrator has the skills to actually implement what is intended. Are the assigned personnel capable of understanding the specification and manufacturer-recommended cyber procedures?
Today there is no practical certification for security technicians that attests to their knowledge and skills in this area. Existing IT certifications cover a lot, but they do not mesh well with the specific needs of the security industry or the skill sets of most integrator techs.
CISSP is a great certification, but overkill for field people. What we need is a security industry certification (SIA, are you listening?) that will close this gap and establish reasonable installer requirements to support good cybersecurity. If a specification is going to include specific cyber language, it is important to know that the tasks are reasonable for a security integrator to implement.
You do not want to water down a spec, but, at the same time, you have to know that the implementer is capable. It may be that the integrator must supplement his team with the proper resources to comply.
Ongoing Maintenance
There are also the matters of system testing, verification and ongoing updates. Many would recommend a vulnerability assessment and, possibly, penetration testing upon completion to spot any holes. Typically, manufacturers are obligated to supply patches and updates for some period of time.
There should be an established mechanism to patch discovered vulnerabilities, with a proactive approach on the supply side to notify the client and provision the updates.
Clearly, there should be a coordinated effort among all stakeholders in a project to reach the goal of a cyber-secured installation. It all starts with knowing and communicating with the customer, and then laying down the requirements on day one to set the stage for a secure installation.
Ray Coulombe is Founder and Managing Director of SecuritySpecifiers and the CONSULT Technical Security Symposium. Ray can be reached at [email protected], through LinkedIn at www.linkedin.com/in/raycoulombe or followed on Twitter @RayCoulombe.
