An intelligent approach to application security.

Living with Insecurity 

Forget about phrases like "guaranteed", "absolute integrity", "assured". There is really only one thing that you need to know about all those systems that you are currently running, mission-critical or not--absolutely all applications are Insecure.

The certainty of this statement was shown by fundamental research in computability from the legendary code-breaker Alan Turing.

One of the essential findings of his ground-breaking work was that it was not possible to automatically demonstrate in advance how any particular computer program would respond to all particular inputs (1). The fundamental implication here is that it is impossible to confirm whether a yet to be tested input to a system will result in a security breach.

Don't Panic!

The logic here seems to imply that whatever we do is flawed, so why bother with trying to be secure? In practice of course, what we need to do is to redouble our efforts against security breaches, avoid being complacent about it and if possible, find new and more effective ways of ensuring that our systems are as secure as possible.

A more intelligent approach to application security can help. By restricting the inputs to applications and systems to an appropriate, benign subset of all possible inputs, we can help guard against damage, whether premeditated or accidental, and whether perpetrated from outside or within the organisation.

Since these inputs are only those that are tried and tested, and known to be appropriate, an extra dimension is added to any security plan.

THE SECERNO PROCESS

Applications and information are vital digital assets. Sometimes, they represent almost the entire value of the business. Secerno technology provides a dynamic and flexible means of protecting these assets. It also provides an automated options to further optimise security based on actual usage.

Understanding Applications

This issue goes beyond information security as a narrow problem. In order to create a system intelligent enough to allow only benign traffic, we need to ask if it is possible to understand applications sufficiently well to answer some basic questions.

Is it possible to:

* spot application usage outside normality?

* see application improvement opportunities? (and solve some automatically?)

* get an overall metric of the quality of the application?

* determine application abnormal usage?

* detect and prevent misuse?

* logically segregate functional areas within a single resource?

* detect application feature creep?

* control application permission creep?

* demonstrate a solid understanding of an application to an auditor?

Organisations spend huge amounts of time and money on these issues. They are incredibly difficult to incorporate when building applications from the design stage, but they can seem close to impossible when nursing legacy systems along.

The Infinite Language Perimeter

Understanding the shape of appropriate inputs is a tough mathematical challenge.

Simple inputs to functions for instance, might be numerical values. But even testing all combinations of numerical values for a small function within an application is difficult. When the input to an application is a language in its own right--the SQL language that a commercial RDBMS might understand, for example--it is almost impossible. Because we are dealing with a computer programming language, it can take as input more than numerical values--it accepts complete programs. In fact, anything that is theoretically computable can be computed by writing the program in SQL. How can we therefore determine the "appropriate subset" of inputs to an SQL database?

We can appreciate the difficulty involved if we know in advance how many different inputs might be expressible.

Most often--and this is true also for SQL--there are an infinite (2) number of inputs that can be expressed in the language. This can be daunting when it comes to considering the security of an application using a database. Of the infinite number of legally constructed statements that the database will act on, which are legitimate normal statements, and which are those that you would prefer were never received by the database?

Blacklisting

One common approach to such matters is to create a blacklist of known sinister statements. Blacklisting puts system owners into an arms-race and poses three insurmountable problems that must be overcome for the approach to be effective.

Blacklisting problem--Only known attack strategies A prevention blacklist can only protect from known sinister approaches. New or previously unseen attacks cannot be defended against. To keep up, system owners must constantly update their signature definitions, and be reliant on external suppliers for the quality of the signatures deployed. Signature systems are often based on simple syntax checking which can easily be subverted by mutating the attack only slightly.

Blacklisting problem--All applications are different Blacklist signatures for one application may not be appropriate for another application. The variation in application design, implementation and features makes adopting signatures without any tuning difficult.

Blacklisting problem--The insider threat Blacklists are focused on external malicious behaviour. Internal misuse does not look at all like the signatures of an external attacker--it will appear nearly normal. We have already seen in the previous point that normal is hard to define in advance as it is so application specific.

It is also worth remembering that there can be an infinite number of attacks. System owners must hope that attackers do not spend too much effort exploring that space to perpetrate attacks on their highly--valuable systems.

From Black to White

At the other end of the "signature" spectrum are white lists. White lists define what is normal for the system being defended, which is simple in principle, and incredibly difficult in practice.

White listing problem--Every system is different An allowable list of operations can be defined by a white list signature set. However, typical signatures are so generic that they can be applied to the diverse set of systems for which they might be deployed.

Typically, these signatures are overly general and offer very little protection. To make white lists effective, system owners must spend a lot of effort in customising and developing signatures themselves.

Beyond Lists

To sum up, blacklists are outward-looking and focus on known external dangers. White lists work by allowing a defined set of signatures, and are inward focused. Neither is effective.

What is needed is an inward-looking approach that leverages a detailed understanding of how an application But what about the insider threat--the situation where a legitimate user--with sufficient privilege and credentials--starts accessing information in the database in a way that is irregular or out of the ordinary? Say, for example, that a key employee with a high level of grant permissions, who normally accesses information in one area of the database, starts accessing information from another area. How can this situation be alerted and defended against?

This situation can be made even more dangerous through a tendency called permission creep.

Employees who change roles often have more privileges granted when they move, but a precise removal of (now) unnecessary privileges rarely occurs--and if it does it can take many months. System managers have to have better understanding of the permissions "headroom" between what users normally need to do their jobs, and what they have inadvertently been granted.

Securing the Infinite Language Perimeter

Ultimately, the only sure way to defend your systems is to understand them fully.

The power of knowledge has long been a weapon in all fields of battle ("Ipsa Scientia Potestas Est") (3). New techniques combining strong symbolic machinelearning techniques with those from computational linguistics can provide application owners with a comprehensible set of patterns that represent the restricted set of the language space used by applications.

This automated approach (4) utilises the specification of the SQL language, combined with examples of the SQL statements arriving at the databases, to extract patterns, which in turn lead to an understanding of how the databases are being used. With a full understanding of systems usage behaviours, it is possible to deploy logical segregation zones--or micro-perimeters--so that only known good behaviours can be allowed, into and out of each zone.

Such barriers can not only be used for detection and prevention of mis-behaviour, but also provide easily comprehensible audit trails to demonstrate compliance. Clearly, a detailed understanding of system behaviour is a fundamental basis for actual control, and the demonstration of control.

In Conclusion

Wrapping up, if we consider the questions posed at the beginning of this paper we can safely say that with a thorough understanding of system usage, it is possible to:

* spot application usage outside normality

* spot application improvement opportunities

* make improvements automatically

* obtain and monitor an overall metric of the quality of the application

* determine application abnormal usage

* detect and prevent misuse

* logically segregate functional areas within a single resource

* determine application feature creep

* determine application permission creep

* demonstrate a solid understanding of an application to an auditor

How is Such an Understanding Achieved?

Understanding the potentially infinite input space for vastly varied applications--particularly those that are already operating--requires a new intelligent approach.

Secerno has developed Artificial Intelligence technology that combines strong symbolic machinelearning approaches with those from computational linguistics. These new techniques make it possible to determine the input language subspace that is appropriate for an application running within a particular commercial context.

(1) This is known as the undecidability result

(2) To prove this, just notice that recursion can be expressed in SQL by an arbitrary number of nestings of SELECT statements

(3) "Knowledge is power" Sir Francis Bacon, 1597.

(4) "Efficient grammatical clusterings--patent pending

Dr Steve Moyle, Secerno

Founded in 2003 by Dr Steve Moyle and Paul Davie, and based in Oxford, UK, Secerno is based on original research into symbolic machine learning techniques led by Steve at Oxford University. At Secerno, Steve has led the application of the research to the development of the Secerno kernel for protecting online digital assets. Secerno is funded by UK investors, including Eden Ventures and Quester, who have a successful track record for backing winning innovators and entrepreneurs.

Steve has a Doctorate in Computer Science from the Oxford University Computing Laboratory. He grew up in the South Eastern wine growing region of Australia. His early academic career at the Universities of Adelaide and Tasmania saw him graduating with a Chemical Engineering B.Eng. and an Applied Computing Grad. Diploma from each university respectively. On arriving in the UK in the early 1990s, he designed and built computer control systems for North Sea gas platforms with Honeywell.

www.secerno.com