You have been hacked.
This isn't a joke. If you have any measure of success in your area of business, this is an eventuality. So you might as well prepare for it.
The following steps you take will probably set you in front of many. Don't be the "low hanging fruit". Cybercriminals always target big and easy game first.
And for those interested, you are just as likely to have been cracked than hacked. We'll make that a subject of later blog.
HOW?
But is there an even better way to address this? Yes. Re-read the title. Assume you have already been compromised or that you will be any minute.
DevSecOps
Like it's older cousin (DevOps), SecDevOps is a collection of good practices to make sure you improve your operational security, from the conception to the everyday operations. Look it up. Learn and embrace it.
There is no single best and official DevSecOps Methodology. You must learn what is best for you.
But allow me to point out a few caveats:
- Just like with DevOps, be very certain that DevSecOps isn't a role.
We don't want to insert yet another constraint, a super specialist or "guru" that can become an operational bottleneck or a single point of failure in our operational chain.
Make it a process to improve your systems. Leverage the knowledge and technology you have and make it an ongoing and continuous learning and teaching experience.
Your people, processes and technology are your best assets. Harmonize their use and you will always do better.
- Be weary of people pretending to be the authority on the subject.
And this my seem a bit contradictory. Since I myself am the "Chief of DevOps and SecDevOps practices" at my company. But note that I head the practices in my organisation. I help establish best practices and teach them, I coach teams and organisations on how to improve.
But here isn't a singular "best way" to set up these practices. It just so happens that I've made a career of making my clients endeavors success stories.
But be sure that I am not the begin all and more importantly the end all of either practices (DevOps or SecDevOps) in my company.
It is imperative that I make sure each team or project is autonomous and able to run their processes independently. If I get hit by a bus tomorrow. Business will continue and what knowledge I have used, is still readily available.
By the way. If you implement either of those practices and you are dependant on the knowledge and expertise, day after day, of a few key individuals, you might as well consider that you are suffering from a "soft fail" and that brings us to the next point. (and subject for a later blog)
Zero Trust
The basis of this proposition is simple but not necessarily easy to manage. We can look at it as a 5 pronged practice:
Your barriers are porous:
The basis of any system, of even a simple secure "box" with a lock and key, is that there must be a way to access it's contents, for it to be operational. I mean, who wants a box that can't be opened?
So assume people will open it, that's normal. Assume that the lock and key is insufficient to protect your sensitive stuff. So, as good as is any firewall, it was meant to be penetrated be someone. And once someone is inside, who is to say things are going to go as expected? So, assume that your barriers have failed, but lets make that failure a bit easier to mitigate.
(That's what I call a "soft fail". One that won't necessarily lead to a disaster, because of the following approach)
As simply as I can put it.
The prongs:
Identify
Ensure that in the design of your applications, you continuously and at every step you validate the identity of the person using the system. This is critical in order to maintain the rest of the security of the system. What is someone manages to steal your credentials? That's why we have more prongs.
And don't just use the "who" to identify, use that "where" and "when". So again, assume identity has been usurped.
Authorize
Perhaps this is a bit of a misnomer: maybe I should say restrict access. Authorize only what is minimally necessary for the identity previously given. Be sure you don't have any "super users" or "super admins" with accounts that are always useable in your production environments. Make sure that any of these "highly privileged" accounts are disabled or expire after their intended use. So, a normal user or a stolen identity can't do too much damage. So now assume that the "penetrated box", has been accessed with an identity that CAN use the system.
Analyze
Use signals to detect unusual activity. Use the who, what, when and where previously locked in. First record all activity. Second, leverage your technology to analyze and discover (Machine Learning?) the patterns of usage that may be "unusual". Define policies of usage that are expected, and when usage becomes different than what you expected use some measures or metrics to calculate a threshold that defines usage is abnormal. Again, assuming someone is in the system and deleting/obfuscating all kinds of data, be sure you know exactly what was being done. Best way to reverse/mitigate the damage later.
Alert
Be sure to have probes that allow you to be alerted when unusual activity happens. Be informed as quickly as possible about breaches, stolen identities and unusual activity. This already part of common practices but tie it in with our previous prongs. And adapt the probes when you add new features to secure your application.
Automate
I cannot overstate this. Automation may very well be what saves you business in case of a serious breach.
I myself have been hacked some time ago. Someone managed to break in and access my stuff because of a notorious problem with Microsoft's remote desktop protocol. They encrypted all my network shares. Locking me out of terabytes of data.
But because I had automation in place, I managed to delete all corrupted/encrypted data and simply replace it with a known good copy.
Now, the admin account on my windows box can't access shares, and when he logs on, I get a notification on my phone. So, when I tell you these things, I speak of experience, not as a "some kind of guru/know it all".
But where you can benefit from my professional expertise, is rather in the first aspect. How to include this in your day-to-day designs and operations.
Good automation makes systems resilient.
In conclusion
We know nothing is perfect. But behaving as such is a bit more counterintuitive. If you start thinking and designing things in your system not only to resist failure, but to cope with eventual ones.
Make improving your systems with proper security practices as much part of it's initial design as it's daily use.
And you may very well manage to avoid a catastrophe.
