Hi George,
From: "George Dinwiddie [email protected] [extremeprogramming]" <[email protected]>
>> 1/4 of the needed features = useful (maybe)
>> 1/4 of the needed security = hacked (probably)
>How do you quantify security such that you can measure 1/4 of it?
True, measuring this quantitatively would be hard, unless you did a series of experiments (put variants of a service on the Internet and see what gets hacked, perhaps?) ;-)
But to get an idea of what security defences are required for a given scenario, we'd draw on sources such as:
- General advice from organisations such as CESG.
(See for example https://www.cesg.gov.uk/guidance/security-design-principles-digital-services-0)
- Specific advice/direction from independent accreditors (see below)- Even more specific advice from independent penetration testers who have examined the software in question
- Advice from our in-house penetration testers, who break into systems for a living, so can give us a good benchmark of what is needed
One would also take into account the risks to the system, e.g. "what's the worst thing(s) that could happen if the system is hacked?".If it's a website for sharing cat videos, then fine. If data compromise could lead to e.g. actual physical harm or death, then clearly more care is needed and more expense can be justified.
>In any event, 1/4 of the "needed" features requires approximately 1/4 of
>the code, which implies approximately 1/4 of the buffers that need to be
>checked for potential overflows. (This checking can be done with TDD,
>BTW.) The UI/API surface would be smaller, and therefore have fewer
>attack points.
I've mostly worked in languages where buffer overflows aren't an issue, but I accept that this particular defence scales with the size of the code - and so does other input validation. But on the systems I've worked on, input validation was an insignificant part of the overall security effort. Much more work goes into the security architecture, PKI, host-based and network-based controls, deployment process (e.g. signed code, secure package repository for deployment) and that sort of thing.
>Consider security aspects for each feature being added. Consider
>security aspects for each component added to the architecture.
>Incrementally.
That's not sufficient if the architecture itself is driven primarily by security concerns, which is often the case in our work.We tackle security at the architectural level as well as at the micro-level (input validation etc).
And the interactions between components are an important source of vulnerabilities - a whole-system view is also needed.
>> - OS lockdown and similar (level of effort almost independent of the functionality to be deployed)
>Isn't this available pretty much out of the box, particularly if you
>install packages as needed, rather than install everything and then try
>to weed out the ones you don't need.
Out-of-the box configurations are often fine, but for specific cases there's a huge amount more that can be done to remove unnecessary services, executables, kernel modules etc.One example was where we needed to deploy hardware into untrusted environments, so it needed to be tamper-resistant (and tamper-evident, in the case of someone opening the box)
>> - setting up network and host-based controls (client and server
>> certificates, iptables, AppArmor, AWS VPCs/subnet layout/security
>> groups, etc) - might be much simpler initially, or not, depending on
>> architecture
>What drives the need for all of this? It seems like an assumption rather than a need for a small app.
That's just a partial list from a recent project, as a typical real example. I wouldn't assume that all of these were needed in every case; of course it depends on the situation and the risks.
If the data itself is very sensitive, then the size of the app is often not the main factor to consider.
Sure, if there are entire components that can be omitted from the first release, then things may be simpler.
But if there are simple versions of most components in early releases, then much of the macro-level security work needs to be done regardless of size.
>> - independent penetration testing (would be good if this could be done a
>> bit more incrementally, but very difficult since testing the whole, not
>> the sum of the parts). Often takes several days per test.
>Pen testing is an after-the-fact technique, not a development process.
Yes, but it is often mandated before we can deploy the application to a live environment. And it may be required again if the application changes significantly.It is a scheduling constraint, and an expense that scales with the number of releases.
>> - external accreditation (not value-adding as such, but required in some
>> domains, and generally tricky to reconcile with incremental development)
>What do you mean by this?
Software for UK Government, military, police, etc generally has to go through an accreditation process.
There's an introduction at https://www.gov.uk/service-manual/making-software/information-security.html
Basically, a representative of the "business", the project team, and an independent accreditor work together to agree the risks to a system, the defences that must be in place to handle that risk, and ensure that the business understands and accepts any residual risk. This is often a detailed and prolonged process that looks at the design, technologies, and human processes (e.g. training, physical access control, ops, monitoring, password policy etc) as a whole.
If the system changes significantly, or is deployed to a significantly different environment, then re-accreditation may be required.
>> If the required defences are light, and/or weighted to the "incremental"
>> end, then no problem.
>
>> If the required defences are heavy, and weighted to the "up-front" end,
>> then their cost/time can IME easily dwarf the cost/time of the initial
>> set of features - it may take many, many sprints to release anything
>> into the wild with real data - it's this situation that I feel is a
>> challenge for an agile approach - not because systems can't be
>> *developed* incrementally, but because there's a long lead time to the
>> first *live* release - and early delivery is one of the few ways we can
>> occasionally convince customers not to go down a waterfall contract
>> route as usual.
>"Heavy defenses" is marketing, not specification. This description make
>the problem look big and monolithic and daunting.
Well, I was talking in generalities a) because I'm trying to make a general point and b) because it's difficult to talk about specific projects in a public forum, for obvious reasons.
For a specific project, one has to look at the specific threats, just as you say.
My belief is that, at one end of that spectrum, the problem IS somewhat monolithic, and thus difficult to manage with a fully variable-scope contract. Round here, the feeling is that we'd perhaps be better off with a hybrid contract that has a fixed-scope initial release of modest size but includes most of the security work, then move to an incremental contract model.As Ron pointed out, one can still *build* things iteratively (and we always have), but that doesn't address the contractual risk side of things.
Regards,
David
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.