Secure by design
Updated: Jul 8, 2019
Designing systems to be secure is never easy, but it is much easier than adding security to a system after it has been designed.
There are lots of factors that contribute to the security of IT systems: user awareness, processes and procedures, specialist advice, hardened infrastructure, and testing, to name but a few.
One of the most important factors is software design. However, we do not often think about security during design. Looking back over my professional education, I have had plenty of training in analysis, database design, online transaction processing, structured programming, and more, but none at all about how to design systems to be secure.
As a software designer, it is tempting to ignore security. Other people are responsible for security policy and infrastructure. You only need to change the design if problems happen, or if a security specialist kicks up a fuss. However, this reactive approach is a dereliction of your duty, and will never lead to a secure system.
Instead, you need to assume that, deliberately or inadvertently, all possible weaknesses in the system will be exposed. With this in mind, you have to design the system so that you have opportunities to inspect and/or block inappropriate access. You have to think of this at multiple points through the design.
To give some examples from our MA2 product:
Web traffic is not by default secure, and can be intercepted. To prevent this, use secure HTTP (HTTPS) which encrypts the traffic.
Any user-entered content runs the risk that users could insert content that disrupts the sessions of other users, often known as "cross site scripting" or XSS attacks. To prevent this, use a product such as Antisamy, which comprehensively analyses and modifies user input to remove potential attacks.
Use of SQL on the database runs the risk of injection attacks, where special data values are interpreted by the SQL as extra commands which can compromise data. To prevent this, never build SQL dynamically, but only use prepared SQL statements which are passed data parameters, which prevents SQL injection.
It is hard to write complicated user interface code that is sufficiently free from defects that it fully enforces security. To overcome this, pass all data access through a more formal API layer (in our case XML-based services) which can check security comprehensively.
Data might be compromised by accident, or through misuse of an account. To minimise the impact, provided a very granular permission structure so that users can only access the minimum amount of data required for their work.
Do design elements like this guarantee security? It is wrong ever to be complacent, and security requires many factors, but thinking about security during design certainly makes a system more secure. Importantly, factoring security into the design provides a set of touch points at which security checks can be implemented, and, should problems arise, they provide places where security can be improved by strengthening, extending or re-implementing the existing checks. It is certainly much better than attempting to retro-fit security on an otherwise insecure system.
Designing in security is not easy, but it is something that should be an integral part of every system's design, and never an afterthought.