There is an ongoing issue in infosec: the never-ending risk. This is a risk that infosec has identified but the project would rather not mitigate. The project cannot refuse to address the risk, but they can do the next best thing: agree to mitigate the risk, but never actually implement the mitigation.
This cycle normally starts with the infosec review and the project agreeing to mitigate the risk, hopefully in a set amount of time. That time rolls around and infosec conducts a review of the progress in implementing the mitigation. This is where things start to fall apart. Rather than answering that they have followed the plan and mitigated the risk, the project indicates that they've made little to no progress. Infosec has no choice but to accept a new mitgation schedule and meet months later. Infosec can't spend its valuable resources following the schedule week to week so another period of time passes and nothing has been accomplished. The cycle continues.
The primary driver of this cycle is that infosec cannot say 'no'. It can't say no initially (or maybe put its foot down on a few issues which did get fixed) and it gets harder to say 'no' as time passes. If the risk was acceptable for the last 6 months, it becomes harder and harder to justify to senior leadership why it won't be acceptable for the next 6 months.
There is an option though. You don't have to say know, you have to say "yes but". Think of it as saying, "yes, you can do whatever it was that you wanted to do, but only while you hop on one foot while patting your belly, rubbing your head, and singing Yankee Doodle." In reality, this may be, "yes, you may use FTP, however each file must be encrypted individually and the password snail mailed to the receiver". The goal is to both reduce risk and disincentivize delaying implementing a real mitigation (such as using SFTP).
An alternate is to decrease the time frame for review. If the project doesn't know when they will have it mitigated, approve use for only 1 month. At the renewal, they should be required to provide the mitigation plan. If they don't know how long it will take to come up with a mitigation plan, give approval for 1 week. At 1 week they should have a schedule for creating the mitigation plan (effectively a schedule to create a schedule).
This only works if they have to prepare significantly more for a renewal than you do. There should be assessments, forms, plans, briefing charts, etc that they have to prepare for the renewal and that you only have to read. The goal is to make renewals more time consuming for them than for you. That way increasing the number of renewals is burdensome on them and not on you, again disincentivizing delaying a mitigation.
Regardless of which way you go, it must be tied to risk. If you cannot show that the reason you are requiring the extra work or quicker turns is to help minimize risk, you really are simply generating make-work which will not be tolerated at your level or at upper levels. Also, you must be absolutely responsive. You once they decide to mitigate the risk you must help and support their solution so that you do not impede the work.
Ultimately, while it sounds harsh to disincentivize delaying mitigation through additional work, in many cases it, is unfortunately necessary. Unless the project is benevolent, they will do what they are incentivized to do and most of the time; only infosec is incentivized to mitigate risk before it is realized. By disincentivising delaying mitigation, you are simply balancing the scales to help ensure a quality product.
No comments:
Post a Comment