The document discusses how some common security practices from the past may now lead to inconvenience rather than increased security. It notes that in modern environments where individual server instances are dedicated to single users or applications, some historical practices around user permissions, installed software restrictions, and operating system choices may now create barriers without providing meaningful benefits. The document advocates focusing on outcomes rather than policies, and assessing whether security measures actually increase inconvenience without improving security.

1. INCONVENIENCE ≠ SECURITY
Wednesday, 6 June 12

2. Securing everything is good, right?
Wednesday, 6 June 12

3. Well, mostly.
• Ongoing maintenance of security policies
• Artificial barriers (‘inconvenience’) lead to lost productivity and
possible downtime
Wednesday, 6 June 12
SECURITY =~ INCONVENIENCE
INCONVENIENCE != SECURITY
LAZY THINKING!
All security is good, right?
Security policies have:
* an ongoing maintenance cost
* an inconvenience factor
Inconvenience leads to lost productivity (I don't know what my application is doing in
production)
and downtime (I can't bring the server back up - I'm not on the VPN).
Fortunately - you don't necessarily need to increase your exposure to decrease your
inconvenience.

4. Avoid ‘wasteful’ security: policies
that provide minimal benefit.
Obvious, right?
Wednesday, 6 June 12
Easiest target: avoid security policies that don't actually provide security benefit.
Seems obvious? It isn't.
Some of the truisms from server security in the 90's and 00's no longer apply.

5. Environments Then
Bob
Steve
Carol
Wednesday, 6 June 12
Some of the truisms from server security in the 90's and 00's no longer apply.
Servers used to be shared between actual, real users (or customers). UNIX security
theory is based around that assumption. Users, groups, permissions, sudo, logging,
all that shit.

6. Environments Now
Bob
Steve
Carol
Wednesday, 6 June 12
These days: your server instance is yours. You've got one non-root logon ('ubuntu',
'aws', 'vagrant'), you use that to sudo.
If your user account is compromised, you're going to take that server offline, fire up
another one, and do a root cause analysis before wiping it.

7. Policies Then
• Compilers don’t belong in production
• Clamp down on installed software
• Hard gates between local applications and users
Wednesday, 6 June 12
Because we're interacting with servers in a new way, some of the security measures of
the past have been downgraded to 'inconvenience':
* don't install a compiler on your production server (that's the 80's talking)
* hard-limit what software is installed/running on your instances (that's what your
ingress firewall is for)
* SELinux (you're not ASIO)

8. Inconvenience Now
• GCC is required to build your nginx configuration file.
• Open ports? This is what we have ingress firewalls for.
• A compromised server is treated as fully compromised,
regardless of access level
Wednesday, 6 June 12
Because we're interacting with servers in a new way, some of the security measures of
the past have been downgraded to 'inconvenience':
* don't install a compiler on your production server (that's the 80's talking)
* hard-limit what software is installed/running on your instances (that's what your
ingress firewall is for)
* SELinux (you're not ASIO)

9. Server-local permissions are for
accident prevention, not security.
‘sudo’ means ‘think first’
Wednesday, 6 June 12
Remember: instance-level permission elevation is about preventing accidents. 'sudo'
means 'think first'. It's also there so you can give developers read-only access to the
resources they need to do their own problem solving: logs, configuration, all that.
That's accident prevention, too: a sufficiently skilled developer, with ill intent, will find
a way to make your life difficult regardless of whether you gave him a production
account or not.

10. Think outcomes, not policies.
‘What am I achieving by limiting this?’
Wednesday, 6 June 12
Now! Let's talk coverage.
I see this all the time: operations staff patching what they understand, ignoring what
they don't. Or, even worse, they'll deliberatly go overboard securing the system
because they know the application is terrible. This isn't useful: if the application gets
hacked, you're offline anyway. Assuming a targetted attack your database credentials
are in an easily accessed, readable location - and the attacker has jumped another
fence you've put up.

11. These Common Policies
• Hard locking application library dependencies
• Insisting on using CentOS because it’s “security focused”
• Disallowing developer access to production logs
Wednesday, 6 June 12
Here's some common patterns and why they don't make sense:
* you're hard-locking what the application's library dependencies .. so the developers are just writing their own insecure, unreliable variants
* you're insisting on using CentOS because it's more "secure" than Ubuntu ... but you're using 'community' packages because CentOS doesn't really
include anything useful or modern
* you're disallowing your developers access to your production logs .. but without an idea of scale, the next deployment will confuse n2 and log(n)

12. Actually Lead To
• Developers creating insecure, unreliable library ‘copies’
• Use of uncertified ‘community’ packages to make up for CentOS
shortfalls
• Developers without production access have no concept of scale,
implement for themselves, not your actual load
Wednesday, 6 June 12
Here's some common patterns and why they don't make sense:
* you're hard-locking what the application's library dependencies .. so the
developers are just writing their own insecure, unreliable variants
* you're insisting on using CentOS because it's more "secure" than Ubuntu ... but
you're using 'community' packages because CentOS doesn't really include anything
useful or modern
* you're disallowing your developers access to your production logs .. but without an
idea of scale, the next deployment will confuse n2 and log(n)

13. Finally,
Credit: SMBC
Wednesday, 6 June 12
Thanks for listening.