Cybersecurity Must be Designed in From the Start

The detailed requirements for conditions for cybersecurity is described by three principles: rooted in hardware, trusting layers of software, and autonomous posture, which have been described in other posts.  To provide effective cybersecurity, all three of these principles must be designed into an application or system from the start.  Only complete use of the above principles can ensure the trustworthiness of a system.  Piecemeal use of these principles, where most of the software is trusted but some layers are not, is likely to leave gaps of uncertainty in the system that may create vulnerabilities to cyberattack.  Modern applications are typically large and highly complicated, often with hundreds of classes, thousands of methods or functions, and hundreds of thousands of lines of code.  Therefore, only careful analysis and design of required and allowed functionality, and just as importantly, unallowed functionality, will result in an application that is highly secure against cyberattack.

Each application is designed in a manner to achieve certain, desired goals.  That design becomes integral to the identity and operation of the application.  So much so, that any significant change to the design also significantly changes the application or system, and may require a redevelopment of the entire system.  Imposing the above cybersecurity principles is tantamount to making basic and integral design decisions for an application.  In the process of designing for cybersecurity, the application will undergo significant changes from the operational design alone, to achieve the goals stated above.

Such changes are generally out of question for large legacy applications and systems due to the costly effort to implement the changes needed, and the side effects on other systems and components that interface with the system.  Instead, an effort to patch or wrap an existing application or system with a new cybersecurity approach is often tried, leaving the original application or system largely intact.  The hope is that most of the benefits of the new techniques will be realized while the impact and costs are minimized.  Unfortunately, these efforts can never be completely true to the intent and execution of the above cybersecurity principles.  The result is a system with some of the characteristics of a security system, but not one that provides comprehensive security for the system.  In terms of cybersecurity, the system thus produced will have many omissions and behaviors that diverge from the desired cybersecurity goals for the system.  In the patched system, the total number of vulnerabilities may be fewer than in the original system, but the cybersecurity will not come close to what would be possible by designing the systems with the above principles from the start as part of the base requirements.

In a sense, cybersecurity is an all-or-nothing proposition, that behooves taking the maximal effort to secure a system simply because the next vulnerability is completely unknown.  A system that is 90% secure is not much different than a system that is 20% secure.  That additional 10% that is left unprotected will quickly be found by the advanced cyberattacker.  What is needed is 99.999% secure, so that the attacker has to dedicate months or years of effort to just have the potential of finding a vulnerability.  That effort will be so costly that the attacker is most likely to try another route to compromise the system.


At Cognoscenti Systems we have applied the above principles in designing our SecureSieveTM cybersecurity technology and our ControlMQTM secure communications product for controls in order to achieve the highest level of network security for controls available.  Find out more at:


Posted in Uncategorized | No Comments »

Autonomous Posture for Components

Building components with an autonomous posture is a core element of good software and systems engineering, but it also provides essential security benefits as well.  Autonomous posture means that components are loosely coupled, where actions of one component, doesn’t have a strict, deterministic effect on another component.  Components don’t order other components to do anything, rather they ask components to do something.  That component may choose to not do what is asked.  This ability to choose is the essence of autonomy.


Components interact with each other, but their essential functionality will not be impaired if another component fails or misbehaves in some way.  Autonomous posture is the opposite of tightly coupled, or brittle, systems where each component relies on other components for its operations, and any failure of another component will cause the first component to work improperly or stop working altogether.  In brittle systems, one component has control authority over another component.


Autonomous poster, when applied to cybersecurity, aids in isolating a compromised component from other components in a system.  Unintended behavior in the component compromised by the attacker will not affect the essential behavior of other components.  Furthermore, the use of secure communications will create components that are isolated from each other in terms of cybersecurity, as the communications to each component is independent of other components.  Indeed, the attacker will need to compromise each component individually, as if starting a new attack, if the attacker wishes to expand the attack beyond the initial component.

Posted in Uncategorized | No Comments »

Full Software Stack Must be Protected for Security

Modern systems are built of layers of software operating on top of the hardware.  From low layers such as microcode and firmware through hypervisors and operating systems, to application frameworks and to the application itself.  Each layer of software depends on the layer below to provide needed functionality.  Therefore, each layer of software must trust the layer below it to provide the correct functionality operating in the expected manner to provide correct operation of the overall system.  If each software layer is trusted to provide the expected behavior, then the entire system should also provide the expected behavior and be trusted.  This dependency on the layer below should also be taken to mean that the layer above cannot corrupt the layer below.  If the layer above becomes corrupted or compromised in some manner then the layer below is not affected by this adverse behavior other than that the lower layer may be used in a manner that is different than expected.  Primarily, correct behavior means that the provided functionality will do what it says it will, and only what it says it will.  For simple functions, like math operations such as sin(x), this behavior is very well defined.  The function sin(x) will return the mathematical value of sine for whatever value is passed in as the argument.  In principle, all functions should be as well defined as math functions, so that uncertainties of outcomes are not allowed and assertions of guarantees of operation can be made for them.  A higher layer of software relies on the aggregate of all the lower software layer functions,and only on this aggregate of lower level functionality, to fulfill it operations.  Therefore, if all the lower level functions can be trusted to operate as expected then so should the higher layer functionality be trusted.

Posted in Uncategorized | No Comments »

Cyber security analysts often discuss the security of a system in terms of CIAA: Confidentiality, Integrity, Availability, and Authenticity.  Cyber attacks that intend to affect the functionality of a system usually try to affect the Integrity or Availability of some part of the system.  However, sophisticated attackers don’t just cavalierly engage in an attack against a new system.  First, they determine exactly what is the purpose of the system, what technologies are used, and what is network architecture, and what components comprise the system.  That’s from Rob Joyce, the head hacker a the NSA.  In a recent talk (1) Rob discussed how they do their offensive work, and what you need to do to protect your systems against the sophisticated attacker like a nation-state actor.

The first thing the sophisticated attacker does is map out your system.  They sit back and observe.  Sometimes for days, weeks, or even months.  The attacker wants to know exactly what components and technologies are in the system, what is the network topology, and where each component is located.  This allows them to plan an attack with the greatest likelihood of success and the least chance of being detected in the system for long periods of time.  This kind of well planned and orchestrated attack is particularly effective in attacking controls systems, as the attacker will need to know where each control management component, sensor, and actuator is located.  The attacker can then use this information to plan an effective attack.

An essential part of observing involves watching network traffic, determining where it comes from, where it’s going to, and what it does.  This allows the attacker to create a map of your entire system that includes all the components, what each one does, when it operates, what other components it talks to, what the network looks like, and where each component resides in that network.

Observing network traffic to determine the use of each component usually requires the ability to read the contents of the control system messages.  Plaintext messages, i.e. ones that are not encrypted, are usually simple to understand by just reading them as ASCII or determining values that are encoded as typical integer and floating point types.  For example, a message that is labeled with a topic of “pump1_set_pressure” leaves little doubt as to what the data included in the message represents.  Similarly, a series of messages with this topic that contains values ranging from e.g. 200 to 1000 over long periods of time suggests the normal operating range for this component.  And perhaps the commands are seen once an hour every hour suggesting the commands are expected at a rate of a regular period.  These are useful pieces of data for a attacker that has malicious intent to ultimately cause malfunction or damage to the system.  Such information would allow the attacker to plan an attack that does not appear anomalous or use messages that are unusual for that particular network or system.  These are the kinds of under-the-radar attacks that are the hardest to detect, and the hardest to prevent.  Furthermore, because the messages are in plaintext, the attacker can easily craft messages of their own design to be injected into the system to carry out their attack.

Unauthorized users observing messages and determining their meaning and use is a violation of confidentiality of the system.  A system that is protected for confidentiality does not leak the kinds of information described in the scenario above.  Operators of controls systems are often told that confidentiality doesn’t matter for their systems as long as the information arrives on time (Availability), is correct (Integrity), and comes with the right signature (Authenticity).  But, as we have shown above, the effective cyber attack, that is likely to disable or damage your system, starts with the “C” in CIAA, and only then moves on to actually try to affect the functioning of the system.  Does your cyber security system protect the confidentiality of your control system?


David Viel is Founder of Cognoscenti Systems, which is dedicated to building new, secure foundations for systems.


Posted in Uncategorized | No Comments »

Cybersecurity Needs to be Rooted in Hardware

After decades of working with a variety cyber security technologies and battling an increasing variety of cyber threats, we now have a significant amount of experience in the cyber domain.  Technologies, such as firewalls, virus scanners, encapsulation in VMs, integrity inspection,  anomaly detectors operate by a variety of different mechanisms.  But, the one salient lesson is found from studying all these techniques is that cyber security needs to be rooted in hardware.

Cyber threats continue to grow in spite of all the effort put into defeating them.  This continuing difficulty with containing the cyber threat has prompted multiple efforts to develop new and better ways of protecting systems and defeating the malicious attacker.  This started out with virus scanners that looked for the signatures of viruses and trojans that were attached to files downloaded to a computer.  As defensed improved malware and attack techniques continued to evolve.  This included things like cross-site scripting and SQL attacks.  Today we have a truly insidious type of malware known as an advanced persistent threat or APT that surreptitiously invades a system or enterprise and slowly works its damage moving as needed from component to component all the while low and slow enough to remain undetected.

When the current mechanisms of protection are thwarted by a new malicious technique it is mainly through evading the technique by going around it.  This is possible because modern computer systems are so complicated that many avenues are available to attack, i.e. these systems have large “attack surfaces”.  One related issue is so tautologically true that it is rarely discussed.  That is, computing systems are programmed with software, and that software can be changed in ways that are unintended by the original developer.  This ability to change software in a deployed system is at the root of how malware and attacks work.

The ability to circumvent defenses, which are themselves software, is exactly because software is infinitely malleable.  In one scenario, a piece of protection software relies on other software.  If that other software is compromised that protection software may continue to operate without ever detecting that its functionality is now compromised.  One solution is to wrap software with other software to protect it.  E.g. using VMs to run processes is just such a method.  If the guest O/S in the VM becomes compromised simply rebooting to a fresh copy of the VM will eliminate that threat.  But, what if the VM is attacked and becomes compromised?  Well the underlying hypervisor can be outfitted with detection software to find out.  But, what if the hypervisor becomes compromised?  One could continually add extra layers of software, but it’s easy to see that this game can continue indefinitely.

Hardware, on the other hand, is not malleable.  That is the behavior of true hardware, not firmware or microcode, or even FPGAs, is defined by physics, and can’t be changed once deployed.  Thus, the hardware forms a firm anchor on which to base the security of a system.  Software can then be tied to the hardware and checked by the hardware for proper operation.  Any modification of the software would be recognized by the protective hardware system, or prevented in the first place.   Novel cyber security solutions based on hardware will provide lasting, effective security today and into the future.


At Cognoscenti Systems we are also committed to using hardware rooted security with our SecureMQTM based on CyberSieveTM technology.  The result is the highest level of network security for command, control, and telemetry systems.

Posted in Uncategorized | No Comments »

Cybersecurity: There isn’t any Pixie Dust

Almost always, when I discuss improving cyber security with a system owner, I get the message that they expect “Pixie Dust”.  Now, they don’t come right out and say it this way, but that’s what their message amounts to.  What do I mean by Pixie Dust?  Let’s look at what systems owners expect and say.

System owners typically have existing systems that have been built up over many years, at great cost and effort, and have a base of developers, maintainers, and users who are quite happy with the status quo.  The last thing that the system owner wants is change.  Change to anything.  Change is scary.  Change is risky.  Change is expensive.  The idea of adding cyber security alone is nearly causing panic for these system owners as it is.  The thought that the system itself may need to change is not even allowed to cross their minds.

After all, they’ve been endlessly informed that cyber security is the IT department’s job.  That their precious system lives in an enterprise and the IT department will provide cybersecurity for that system.  So, of course the thought that their precious system itself is insecure and, must be made secure, is quite a stretch.  Furthermore, when told that they need to secure their system the owners believe this means some additional security hardware will be added to their networks.  Hardware that won’t interfere with the operation of their system of course, and that they won’t have to maintain or deal with in any way.  Or, in the worst case, perhaps a small, barely noticeable process will be run on their machines, much like a fancy virus checker.  That’s something the system owners can relate to, as they have virus checkers on their home PCs, and it’s not so bad.  A small process on their machines won’t really interfere with anything, so that burden can be borne without a heart attack.

What the system owners expect is the security people to come in and do their job while they go to lunch.  When they get back, their systems will now be secure, and they can go on with their business as if nothing ever happened.  In other words, the system owners expect Pixie Dust.  They think that while they’re gone munching on lunch, the security people will take out their magic pouch, grab a pinch of Pixie Dust, and sprinkle it on the system, and magically the system is now secure.

Well, I hate to be the one to inform the system owners, but there isn’t any Pixie Dust.  The real issue is that over the years, the systems we’re built up without the kind of security that we have in mind today.  So, the system itself will need to change.  That usually ends the conversation.  And why not?  Other purveyors of security systems actually do promise Pixie Dust.  They say we have the best firewall, IDS, IPS, machine learning, anomaly detection, cyber gadget du jour, etc. available.  And all of this will not require you to change one iota of what you do with your system today.  Which pleases the system owners quite a bit, so they choose one of them.  Everyone else is choosing one of these Pixie Dust purveyors, so it must be OK. Right?

Perhaps that is why our systems are so insecure today despite spending an enormous amount of money and time on cybersecurity.  No one wants to address the root causes of the problem and fix them.  The systems themselves, and the foundational protocols and technologies on which they are built, are insecure.  Now that cyber attacks have moved beyond data systems to cyber-physical systems like robotics, medical devices, IoT, and industrial controls, the situation only get more dire each day.  And until the foundations are fixed, we will continue to have insecure systems, and stories of the latest attack on the cover of the Wall St Journal.


David Viel is Founder of Cognoscenti Systems, which is dedicated to building new, secure foundations for systems. Contact at:  Find out more at:

Posted in Uncategorized | No Comments »