Bad Behavior

For most of the evolution of programming and IT in general, the actual behaviors exhibited by an application, system or device have been controlled via code that a developer writes into some compiled executable.  The way an application responds to a button press, how a conversation is secured and even when and how devices turn on and transmit data is all hard-coded.

Now there are quasi-exceptions to this rule in the form of workflow efforts but even those constructs reduce behavioral options to either/or commands.  In other words – either follow this hard-coded path OR follow this other hard-coded path.

This approach is not necessarily bad – writing code to control behavior is very fast and systems are designed to handle this type of approach.  Most operating systems focus on rapidly executing hard-coded behaviors to handle user inputs.

But what happens when a given behavior goes wrong or, in the security world, a given series of behaviors leads to some vulnerability that a hacker happily exploits?

The reality is that fixing hard-coding behaviors is arduous to correct, test and deploy.  Often the fixes are intrusive and can cause more issues than the original hack.

Clearly something needs to change.

Bear looked at this approach and we realized that a much more resilient system would externalize behaviors as much as possible and only hard code generic operations.  In Bear, for example, the code enables the ability for two devices to identify and authenticate one another but a policy determines everything else – what protocol to use for identification; how to use that protocol; the authentication process and so forth.

This approach enables a very rapid response capability for a new attack – it is literally just a (albeit highly-secure) configuration change.  Instead of writing more code, testing that code and slowly rolling out patches, Bear customers can quickly configure out the bad behavior and upgrade their system in minutes. We feel that moving behaviors to a configurable, protected policy enables responsiveness never seen before in security.

But does anybody care?

It has been interesting talking with companies that do not really care if they are truly secure as long as they can show that they are using some level of standardized protection.  In a classic pass-the-puck strategy, these companies similarly do not care how long a patch takes to come in as long as they are not on the hook because of that missing patch.

So what do you think?  Is this ability a good thing, bad thing or who cares thing?  Give us your thoughts.

Thanks!

The Bear IoT Team