Random Acts of Architecture

I attended the Australian Information Security Association (AISA) National Conference for 2011 on Wednesday 9th November. For an event free to AISA members, the speakers were excellent and I recommend this to anyone involved with or interested in IT security in Australia. What follows is a summary of important or interesting points and how I believe they relate to software architecture.

Using anti-virus, firewalls, intrusion detection systems and so on is best practise but attackers are always finding new attacks that circumvent these controls. IT security is slow to adapt and, as Einstein said, “doing the same thing over and over again and expecting different results” is the definition of insanity. With IT increasingly forced to deliver sensitive data to users via convenient rather than secure methods, such as via social networking or on consumer owned mobile devices, the focus needs to shift from protecting devices and systems to protecting information. As Michael Jones from Google pointed out, organizations are being forced to be both open and private and to “deliver sensitive information to the edge”.

Moreover, as John Stewart from Cisco said, (paraphrased because I missed the exact quote) “there are three types of organizations: those that have been hacked once, those that have been hacked twice and those that don’t know (hacked three or more times)”. IT security needs to move from a preventative model, aimed at stopping all intrusions, to a containment model, one which recognises that compromises occur and aims to preemptively contain or localize the damage. Ruth Marshall from Novartis compared IT security to healthcare and that sometimes “the cure [IT Security and the constraints it places on users] can be worse that the cause [the security issues mitigated]” from the user’s perspective and that maybe a “palliative care” model is better.

Indeed, this second point highlighted the security disconnect between organizations and individuals. Individuals care little for security, as shown by the continued use of social networking and similar sites despite recent privacy and security concerns. Organizations do care and, instead of holding ill-equipped individuals accountable, assign this responsibility to the CISO and the IT security department. However, individuals then blame IT security when it does its job, such as pointing out the lack of regulatory compliance and privacy with commonly used social networking sites or the lack of control when consumers user their own devices for work (as mentioned above).

As non-functional requirements, the software architect is often  responsible for security and privacy. The software architect also influences or dictates where data is stored and how it is consumed. There is no accepted formula or standard for what security measures should be used in a product. One approach is to offer two or three choices for the most sensitive parts of the product; complete with the pros and cons of each, the architect’s recommendation and references to requirements (particularly integration, compliance or regulation). Work with the product manager and director on a solution and use it as a guide through the rest of the feature or product. This increases communication and spreads the responsibility, too.

Another interesting point raised at the conference concerned the potential introduction of mandatory Internet filtering in Australia. None of the presenters were in favour of this because it simply will not work and Bruce Schneier argued that technical groups, such as IT Security, need to become more politically vocal. However, he argued these groups need to argue the technical pros and cons while leaving the policy details to others. Technical groups have expertise and experience, therefore credibility, in technical areas (“Technical reasons A, B and C mean this will not solve the problem”). Adding judgement or policy to this (“Problem X is not the real problem” or “Problem X sucks anyway”) weakens this stance because listeners may assume technical details are manipulated to support a political view. Vice versa is also true.

Software architects are often required to defend their decisions or critique others’ for non-technical people. Sticking to the technical details and drawing technical conclusions from that is a very credible way at presenting or establishing your point of view. Also, coming form an engineering-style background, many new software architects view decisions as black or white affairs where the correct answer is “obvious”. Taking time to build a case with supporting facts can avoid miscommunication and frustration while opening the architect’s mind to other solutions. This is not saying that a software architect cannot or should not care for non-technical issues, more than he or she needs established credibility to do so.