Secure by design

Alexey describes the usual cycle: a product is built with security kept apart, the security people appear just before release, and then come the fixes, reworks and redesigns. Ekaterina Rudina, who at Kaspersky Lab works on security analytics for industrial systems and the internet of things and collaborates with national and international standardisation committees, calls that a firefighting strategy: a critical vulnerability here, an architectural flaw there, every finding adding to one growing problem until you say stop. Her alternative is the Three Little Pigs: the straw house fell down, the house of twigs fell down, the brick house, oddly enough, fell down too, and only on the third attempt comes the question whether you could build so the house stands on its own, does not wobble, is not blown through by the wind and holds even when someone comes to destroy it. The same approach applied to code and to a system in the broad sense is Security by Design.

Sergey Rogachev, who builds the secure KasperskyOS platform and came into security from operating systems and virtualisation, adds that by definition this is not one concrete methodology but a general mindset from which different practices grow. Thinking about security at the end of the road is too late, because the design can no longer be changed and architectural fixes are hard to implement, so the work shifts as early as possible, down to the product concept stage, before functional requirements exist. That is Shift Left. The spectrum is wide: the formal Microsoft SDL, Kaspersky Lab's own methodology, less formal heuristics, design patterns, basic principles. Alexander offers a frame from his own experience: first Dev and operations were merged, then letters kept being appended to the acronym, Sec, Data. The point is the same. Quality, reliability, security and data handling are not bolted on afterwards, they are designed in. Security is simply further from a developer than, say, testing.

Sergey explains why it is worth doing, unusually for himself not from the technical side: the business keeps hinting that it all comes down to money. Deferred security is not only about angry reviewers sending you back for rework. The product may not be ready to deliver value to customers: a system is meant to provide some property from the confidentiality, integrity and availability triad, and it does not. What follows is patch management, architectural rework and new redesign iterations, all at the support stage, which absorbs people, money and machine resources. The classic SDL does lengthen the path from idea to release, but support comes out cheaper. Alexander turns that into total cost of ownership: writing the code is one thing, maintaining, evolving and patching it for years is another, and nothing is more permanent than the temporary. To the business he suggests talking plainly: features will cost more, but nobody will be fixing everything during an incident or a leak.

Ekaterina prefers a Russian term that translates as "constructive security" and reduces it all to goal setting: what exactly counts as security for this particular product. Forty or fifty years ago it was simple, confidentiality, integrity and availability, all of it about information. Today there is also the readiness of systems, the ability of a power plant to produce a required amount of energy within a deadline and no less, the speed of reaction to events, reliability, long treated as a separate notion, and privacy, which can conflict with public safety. The cheap recipe for any project: in half an hour write out three, five or seven points on what counts as safe behaviour for your application and what does not. Alexander explains why goal setting gets forgotten: before an incident happens it is hard to believe in it, and measuring security up front is as unclear as measuring reliability. Sergey adds his team's acronym for security goals and assumptions: a device in a residential stairwell and one inside a guarded factory defend against different classes of threat, a legitimate reason to cut corners somewhere.

Does a startup that has not yet earned its lunch need Secure by Design? Ekaterina answers through scalability: with import substitution in the air, a local startup builds not firmware for one device but a platform for programmable logic controllers, and a platform has to be customisable. Then a real example whose name she deliberately withholds: an industrial automation framework runs as a Linux application under root, and plugins with custom code are loaded straight into the address space of that process. Any vulnerability in a third-party plugin compromises the whole platform, every mistake earns a high CVSS rating, and advice to run a static analyser changes nothing; the framework has long since spread around the world, and the mince cannot be put back through the grinder. Alexander answers through a risk model: a week-long partner project with no personal data and some promo codes is one thing, an engine carrying customer operations and payments quite another. Corners can be cut on a prototype, but once the hypothesis is confirmed the solution is rebuilt and the stopgap is not let into production.

What if the product is already built insecurely and attacks have picked up? Put out the fires first, Ekaterina answers. Sergey adds that the rest has to be iterative: run an analysis, find the untrusted pieces that work with user input, and move them into containers or compartments limited as far as possible in privileges, with a single known channel to the outside. Google Chrome is built roughly that way, with the parts that handle page code and scripts deprivileged, so that when such a compartment falls only availability suffers. On where to learn this the participants differ gently: Ekaterina backs a basic engineering education and experience from adjacent industries such as functional safety in car manufacturing, Alexander backs books, among them Google's book on secure and reliable systems and its treatment of incident management through a security lens. Another view from the studio: Secure by Design cannot be learned from books and one of the participants has seen no serious courses, so what you pump up is software architecture and a general grasp of information security, to which Bishop's fundamental work is a good route.