Fixing Security Flaws
A recent Microsoft zero-day exploit (you know the ones with no fix) is running rampant in the SMB world and nobody knows how long it will take Microsoft to close the hole. The reasons as to why Microsoft does not immediately provide a fix in the focus of this post.
When looking at most applications, the way that app responds to a tap, gesture or input is all statically written in code. This coding approach is great for fast responses, ease of debugging grammatical errors and so forth…
But it is horrible for security.
Most security exploits are the result of behaviors being used or combined in nonobvious ways. This translates into massive code revisions, huge development efforts and, regardless of the size of a company, considerable effort just to fix one flaw.
As the number of flaws exponentially increase, this problem is becoming exacerbated, to say the least. In fact, most exploits take months to fix and that is just not going to work moving forward.
Despite the apparent critique of current coding practices, we do not think the hard-coded behavioral approach is necessarily wrong – just wrong for security. We strongly feel that these applications should NOT be focused on security at all. Instead, we think that those applications need to rest of a strong, adaptable security foundation that handles their protection.
As for our security foundation, however, we promote a high level of workflow engine-based processing wherein no behaviors are hard-coded. In the Bear platform, all behaviors are controlled in policy and those policies can be securely changed at any time with no impact on hosted applications. While this generic client approach is much harder to create, it enables extremely rapid responses to ever-changing exploit attempts.
If Microsoft had written its SMB system as Bear has created its platform then that zero-day exploit would have been corrected within minutes…and not…err…well who knows how long it will be until this exploit is overcome…