3 ms·
Yeah, it's not too bad. Odds are, you were probably doing it already anyway. My recommendation, learn how to translate "unquantifiable" ideas to quantifiable
by ifoundthetao 9y ago
Yeah, it's not too bad. Odds are, you were probably doing it already anyway.
My recommendation, learn how to translate "unquantifiable" ideas to quantifiable ones. You can do this through a simple tool called an "OKR", which stands for "Objectives, and Key Results".
OKRs are generally built for quarterly runs. No need to stick to that. But come up with four objectives, split them each into six or so actionable items. So those actionable items can be split up into tasks, sprints, etc..
At that point, you will have quite a bit of work set up, and it will be easily measured. Take the percentage completed of each of the tasks, which make up the percent completed of the Key Result, and then the percentage of the Key Results completed make up how far along in your objective you are.
The objectives should spread across several different domains that you're directing, and your priorities should take care of what goes in there.
Take a good amount of measurements on those, do Gap Analysis' often, to find out why you overshot, undershot, etc., and keep track of that information. Do Root Cause Analysis' often as well, so you can find out what is really going on.
The crux of it all really depends on what you're willing to do with your team, and how accountable you're all willing to be held. Without their backing on your objectives, it'll be a bit more difficult. So if they understand what it is that you're trying to accomplish, and they see your leadership (i.e. owning up to all mistakes, and sharing all accomplishments), they will back you. But the keys to that are understanding the goals of the objectives (not just the objectives, but the reason that they're up there).
If you can do those things, you'll find it very easy to manage.
Other more specific things might be setting up controls so that you can easily audit the SDLC: get "sensors" and "measures" in place. Sensors would be something like a CI server, automated testing, security unit tests, post deployment tests, code sniffing, static code analysis, dynamic code analysis, regular fuzz testing, ensuring that your environment is locked down with file integrity checking, track third party tools that are in use for any known vulnerabilities, get software bill of materials (while you're at it), get a known authorized hardware list, get a known authorized software list, have a monitoring system for when these are violated, and get the response time down to 1 - 24 hours.
The measures will be something like:
* adding a benevolent unauthorized machine to the network.
* adding benevolent unauthorized software to an unauthorized machine in the network
* adding benevolent unauthorized software to an authorized machine in the network
* make a change to a file that does not decrease the security of the environment (ex: change from 10 char password complexity to 14 char password complexity), and see if the file integrity check finds it.
Basically for every sensor, you want to have a measure that checks it, otherwise you won't know if you have it set up properly, or if it is broken.