Container technology, specifically Docker, is becoming an important part of any enterprise. Even if you don’t have development teams targeting Docker you may have a vendor wanting to deliver their software in container form. I’m not so happy with that, but we’re going to have to live with it.
In order to properly control the risk around this I feel it helps to have a feeling for the basics of what a Docker container is, and since I come from a technical background I like to look at it from a technology driven perspective.
Last year I wrote about how I used Letsencrypt to handle the SSL certificates for this site. In this entry I’m going to take a step back and discuss the basics of what an SSL certificate is and the steps involved in managing them. There’s a lot of jargon involved, which can make this seem more complicated than it already is.
Note that in this post I’m likely to use the words “SSL” and “TLS” interchangeably.
I’ve previous written about encryption and hashing and why things like customer passwords should never be encrypted.
Sometimes, though, you need encryption because you need to get the raw data back.
Now you can apply encryption at different layers. Some are easy; some are hard. What you need to be aware of, though, is what they protect against. There is no one-size-fits-all solution
A standard app In a common scenario we may have an application that writes data to a database; that database persists data to disk.
A number of years back I saw a mail thread around Java performance. One person made the claim that Java was slow; if you wanted performant apps then write in a different language. This matched my experience, so I felt a little confirmation bias. However the reply really made me think; this may have been true 10 years ago (and, indeed, it’d been over 10 years since I’d done any real Java) but modern techniques meant that Java was perfectly fast.
If you’ve ever built any enterprise level system you’ll be aware of the needs of performance and resiliency. You may do performance testing on your application; you may have a backup server in a second data center; you may even do regular “Disaster Recovery tests”.
And yet, despite all these efforts, your application fails in unexpected ways or isn’t as resilient as you planned. Your primary server dies, the DR server doesn’t work properly.
WARNING: technical content ahead! There’s also a tonne of config files, which make this page look longer than it really is, but hopefully they’ll help other people who want to do similar work.
For many years I’ve been using variations of the Linksys WRT54G. I first switched to this router when freeware ROMs became available; I’ve used DD-WRT, Tomato, OpenWRT and others.
One of the golden rules of IT security is that you need to maintain an accurate inventory of your assets. After all, if you don’t know what you have then how you can secure it? This may cover a list of physical devices (servers, routers, firewalls), virtual machines, software… An “asset” is an extremely flexible term and you need to look at it from various viewpoints to ensure you have good knowledge of your environment.
A while ago I wrote about some of the technology basics that can be used for data persistency. Apparently this is becoming a big issue, so I’m revisiting this from another direction.
Why does this matter? In essence, an application is a method of changing data from one state to another; “I charge $100 to my credit card” fires off a number of applications that result in my account being debited, and the merchant being credited.
We’re all used to using passwords as an authenticator. However, passwords have a number of problems. In particular people tend to re-use them on other sites (so if one website was broken into the password used there may also work on another site). Also passwords are susceptible to replay attacks (even if you force a password change every 90 days, there’s still a large window of time where a stolen password can be used).
Let’s say you run an ecommerce web site. As part of this people create accounts. Naturally those accounts have passwords. Do you encrypt those passwords before storing them in the database?
All you people who put your hands up and answered yes… put them down; you’re wrong. You should hash the data instead. This may sound like a “tomato/tomato” thing, but it’s not.
Encryption and hashing may both be cryptographic in nature, but there’s a subtle difference between them.
