By Ron Brash and Marc-Etienne Bergeron
Within the confusing sea of security feature claims by vendors and experts, just how could an asset owner or decision maker ever choose the correct solution? The answer begins with education on three sides: Asset owners/organizations; industry experts, and vendors and integrators.
Let’s face it, in today’s heightened cybersecurity awareness, organizations are publishing marketing/buzzword laden documentations spouting product claims.
To cut through the FUD, we selected questions to illustrate educational scenarios for decision makers within any organization. In addition, these questions could be posed to vendors and solutions providers at the earliest of selection stages.
Here are eight essential-areas to guide decision makers following this mantra: “Whose interests are first? Mine! As a potential buyer, I’m responsible and I should be diligent where possible. Trust, but verify contractually from the beginning of the process.”
1 Does security (better engineering) need to be built into the product as a purchase requirement?
In many regards, a product to be deployed in your organization needs to be secure, and not introduce new real and potential risk while widening the attack surface. The fact security needs to be implemented throughout the product, any connecting infrastructure, updates/upgrade cycle, usage/onboarding processes, and documentation/examples are all examples where security components are absolutely necessary such that new risks are not inherited either unmitigated or unacknowledged. For example, the new security appliance in your organization just became another node to be monitored as part of vulnerability management (VM); it runs an operating system, potentially connects to the Internet, receives updates and more.
One way to enforce security integration is by introducing security (and verification) as mandatory requirements within the RFP and contractual processes, which may include:
• Secure coding X standards are implemented and validated independently by Y organization
• Ability to be onboarded into asset management solutions for vulnerability management
• Mandatory and assured security fix cycles according to a defined Service Level Agreement (SLA) of X days after CVE publishing
• Logs generated by the device must be pushed to organizational alert infrastructure for incident response and accountability activities
Any deployed solution should not only have periodic security/software updates, risk assurance letters, but also security by design. Therefore, as a decision maker, absolute understanding of all features or methods within a product are not required, but indeed acknowledgment of potential risks from purchase to retirement of a product are your responsibility – the last thing you need is more risk when trying to reduce risk.
2. Are all Total Cost of Ownership (TCO) factors accounted for?
Security solutions are an essential investment. When an organization purchases a solution, it does not aim to add additional costs, but unfortunately, extra costs exist. As part of the solution’s test-drive or early into the sales cycle, those leading the evaluation process are required to examine all the possible costs associated with the solution. Security to be embedded into the solution should not be an additional cost, but expenditures such as the following should be considered:
• Resources required to champion/socialize, deploy, maintain, and monitor the solution (including actioning upon alerts)
• Organizational costs relating to end-to-end testing (including solution operationalizing costs)
• Further integration costs into existing solutions and infrastructure
• Alterations or creation of related organizational governance
• Costs for electricity, connectivity and supporting infrastructure
3. Are resources consistently able to actively secure assets and take action?
Consider People, Process and Technology. Are qualified personnel seated behind keyboards to accurately analyze and manage alerts? Are alerts even actionable or accurate? Will assigned resources eventually suffer alert fatigue? Can the organization perform risk reductions upon vulnerability detection as part of a solution’s marketing claim?
All of the above are valid questions and should set the tone for an honest “internal” discussion within the organization, and the decision makers. Technology is never a silver bullet, but its success is a compounded effect of the infrastructure supporting it, and people/process leveraging it.
4. Can solution outputs easily merge into existing/new (IT) infrastructure?
Most organizations have a fairly well-understood IT infrastructure already deployed, and road maps to further evolve. Assuming, the organization has a sufficiently mature IT infrastructure, decision makers can chose to “piggy-back” a well-performing solution to reduce TCO and garner improved Return on Investment.
In performing a new deployment, have we examined all costs associated with streamlining technologies? Can the OT solution integrate with current IT solution(s) under carefully examined and tested circumstances? Is there overlap requiring integration with solutions such as firewalls or proxies, and reporting infrastructure?
5. Does this solution truly provide value, and can concretely support any claims?
Here is where another honest discussion is required to examine the organization’s security requirements and risk appetite. Can a chosen solution provide adequate coverage of all critical assets or a subset? Are there compatibility concerns with deployed PLCs, HMIs? Will enterprise truly receive improved visibility of OT network(s) and sites? Will the solution provide enough information to produce reporting artifacts sufficient for high-level management? Are all technical security aspects or features actually performing as promised? Are there risks?
In short, if decision makers cannot see the value in a solution, will the security team be able to get the funds to secure the OT network; can an organization really take that risk? The solution: Test and verify, but not on the organization’s dime – the vendor should absorb that as a cost of doing business.
6. Will this product exist in X years? If Y vendor is acquired, what would change?
Assuming the solution will be for an extended period of time, it should follow the organization would ensure support and replacement options.
If a vendor was to be acquired, would that affect product support, maintenance (patching and updates) or would that add controls to the yearly audit? Would that affect any signed contracts or are there any consequences that should be considered? What about if the product was to go End-of-Life (EoL) sooner than expected? Or the company ceases to conduct business?
7. What is the product assessment and deployment approach/processes within the organization?
Many organizations have a mature procurement process for services and technology alike. Unfortunately, ICS/SCADA and critical system cybersecurity solutions are rarely “plug and play” and neither is the assessment process low-risk or clear cut. In fact, assessment or deployment is a project in itself, which also includes change management processes, standards/organizational compliance, and a variety of other requirements.
8. Are effective security/engineering controls currently in-use and actioned?
If a home is built on severely crumbling foundations, and the electrical wiring is replaced, the effectiveness and relevancy of the upgrade is lower in terms of priority. Cybersecurity is similar. If your key assets are not protected or operating as expected, then adding a fancy new solution for actioning X’s alerts may not be a priority, nor would it be as effective as if the organization was in a position to leverage those new controls.
Again, if basic and essential controls are not present, then monitoring analytics on the process might not be effective either; like installing an alarm system when there are no locks on the doors or windows.
If some essential controls and systems are present, it is important to leverage and gain value from “easy wins” if possible. Technology effectiveness is contingent on current controls, infrastructure, process and procedure. Leverage what you have, often many of the basic tools such as firewalls and log collection are already deployed, and do not necessarily require skill sets that greatly diverges from what is currently present.
Decision makers need to focus on several key questions to help them secure organizations. After all, safety is paramount, and any disruptions could result in fiscal penalties, operational disruption, brand tarnishing, loss of life, and even – reduction of employment opportunities. Security is not for just IT and even OT folk, but rather for the whole organization, which translates directly to “the bottom line” and keeps operations feasible.
Ron Brash is a manager and SME at a Canadian Cybersecurity practice based out of Montreal, Quebec. He focuses on providing technical knowledge in the critical infrastructure domains, selected security topics, and advises in areas ranging from technical risk assessments, security architecture review, OT integrations, and controls review.
Marc-Etienne Bergeron is a consultant at a Canadian Cybersecurity firm located in Montreal, Quebec. He co-drives/manages a number of mandates relating to cybersecurity controls, incident response playbook creation, risk analysis, evidence review, and security policy/governance. Marc has a BA focusing on systems and information management.