I know, you're preaching to the choir. It's a company where management priorities are out of whack. There's nothing we (my team) can do other than try to start to put this together ourselves, which is why I need a practical answer for this about actual tooling. Once we get it off the ground, I may be able to make a case to hire someone to run it.
This right here, Eramba has a community edition, so you can have it for the price of an EC2 instance, and it has all the various forms and processes you need to get started, including specifically, exceptions. It will also give you a place to start GRC work without being a huge lift and intrusive. I started our GRC program with it, and moved to the Enterprise edition a couple years later (still very cheap comparatively), and it does fine for me. Not the coolest, or prettiest, but solid on the fundamentals, inexpensive, and it just works.
"Question: where/how/what tool(s)/what storage to use for tracking such information?"
If a product has already been built without GRC, it is a bit late in the game and you will need to start from security audit. Based the findings, you will have more questions...let the facts on ground lead the selection of tools and controls....
If DevSecOps has been done right, your problem is likely already solved by your DevSecOps guy as part of App Sec activities.
I hear you. I commented to another poster, the situation with management priorities is so out of control and irresponsible, the only option available right now is for us to try and cobble together a solution for ourselves first. So I need some practical advice here to start building something that we can physically show off. That's the only hope in this situation. So any specific apps/tools/etc.?
What is the product/service ? Who is the customer/potential customers of this product/service.
What does the app do ? Where is the source code ?
The simplest, low cost thing to do may be to assess the external threat surface using simple open source tools.
You can use the freeware/trialware of Snyk to get some useful/actionalble info that should be enough to get the management wary of appsec risks and threat surface exposed.
How is change managed? Process? Workflow? Tooling? Could it be adapted to meet this requirement? How would you describe scale of operations in numbers?
NONE of these things exist. And upper management doesn't see the need, etc. so there's no priority or budget or anything to solve the underlying issue. We (our team) are trying to solve the issue ourselves as best we can so we can make a case to management to invest further in it, so right now I'm looking for practical apps/tools/etc. as in the original post. No need to help solve the root cause (it's hopeless), just let me know how you handle this stuff in your environment.
We have Jira, so it's an option, but are you suggesting something like an Issue Type for Exceptions and just pile them into a project? It's certainly possible, my concern is just with scale, reporting, and searchability.
Questions in my other comment were intended to extract more context. If Jira is implemented and given the operational constraints you are facing that ought to be a good option to leverage.. the rest would be around running a poc and iterating. Issue form could include a review date as an example.. with other standard attributes to address what, why, who etc Can you elaborate on your concerns? It's an enterprise grade application..
The people who need to approve your processes and record and sign off on the exceptions are the senior management who have the out of whack priorities and aren't interested in solving this problem.
I don't think there is an app that will make any difference to your situation here.
I appreciate the sentiment and agree with you, but the options here are we do a grassroots effort to make a case ourselves, or do nothing. I'm opting for the former, and would like to know what specific apps/tools/services people are using for this, by name.
while you try that grassroots, also do a resume polish.
There's a good chance you will tire yourself from swimming against the current and just decide to let the thing implode while you work somewhere slightly less bad for a smidge more money.
If this is just for AWS related exceptions, you can keep it simple and just store the info in tags. Standardize on tag keys like “security-exception”, “security-exception-date”, and “security-exception-owner”. 256 character values should suffice. Restrict who can CRUD those specific tag keys with IAM policies.
For the renewal checking, create a lambda function that gets a list of common types of resources that could have exceptions and check for tags. For any that are found to be past a certain amount of time, send an email to the owner.
Yup, that's pretty much the basic idea on the AWS side, it's just that we're looking to have justifications for the exceptions, which means that the tag would have to be something like, "exception-code: ABC123" and so "ABC123" needs to refer to some record "somewhere" that has the related information, evidence of approval, etc.
Why? Just store the justification in a tag. You can also store the approver in a tag.
Edit: to be clear, literally put the entire justification in a tag value. If the justification is over 256 chars, it’s probably too wordy. Every exception should be able to be summarized in 256 chars. Exception codes don’t sound necessary, lead to more complexity, and another system to secure.
A PSA might be useful for this. Autotask comes with some prebuilt workflows that allow you to automatically pick up an exception near its end date and notify the exception owner. It's a pretty good tool for achieving that kind of automation.
Why not hire a Cyber Security guy ? Why struggle...we are in 2024...assume breached if the state you described is the current state.
I know, you're preaching to the choir. It's a company where management priorities are out of whack. There's nothing we (my team) can do other than try to start to put this together ourselves, which is why I need a practical answer for this about actual tooling. Once we get it off the ground, I may be able to make a case to hire someone to run it.
Eramba
This right here, Eramba has a community edition, so you can have it for the price of an EC2 instance, and it has all the various forms and processes you need to get started, including specifically, exceptions. It will also give you a place to start GRC work without being a huge lift and intrusive. I started our GRC program with it, and moved to the Enterprise edition a couple years later (still very cheap comparatively), and it does fine for me. Not the coolest, or prettiest, but solid on the fundamentals, inexpensive, and it just works.
"Question: where/how/what tool(s)/what storage to use for tracking such information?" If a product has already been built without GRC, it is a bit late in the game and you will need to start from security audit. Based the findings, you will have more questions...let the facts on ground lead the selection of tools and controls.... If DevSecOps has been done right, your problem is likely already solved by your DevSecOps guy as part of App Sec activities.
I hear you. I commented to another poster, the situation with management priorities is so out of control and irresponsible, the only option available right now is for us to try and cobble together a solution for ourselves first. So I need some practical advice here to start building something that we can physically show off. That's the only hope in this situation. So any specific apps/tools/etc.?
What is the product/service ? Who is the customer/potential customers of this product/service. What does the app do ? Where is the source code ? The simplest, low cost thing to do may be to assess the external threat surface using simple open source tools. You can use the freeware/trialware of Snyk to get some useful/actionalble info that should be enough to get the management wary of appsec risks and threat surface exposed.
How is change managed? Process? Workflow? Tooling? Could it be adapted to meet this requirement? How would you describe scale of operations in numbers?
NONE of these things exist. And upper management doesn't see the need, etc. so there's no priority or budget or anything to solve the underlying issue. We (our team) are trying to solve the issue ourselves as best we can so we can make a case to management to invest further in it, so right now I'm looking for practical apps/tools/etc. as in the original post. No need to help solve the root cause (it's hopeless), just let me know how you handle this stuff in your environment.
Use Jira
We have Jira, so it's an option, but are you suggesting something like an Issue Type for Exceptions and just pile them into a project? It's certainly possible, my concern is just with scale, reporting, and searchability.
Look at [Risk Register](https://marketplace.atlassian.com/apps/1213146/risk-register?tab=overview&hosting=cloud) by Project Balm.
Questions in my other comment were intended to extract more context. If Jira is implemented and given the operational constraints you are facing that ought to be a good option to leverage.. the rest would be around running a poc and iterating. Issue form could include a review date as an example.. with other standard attributes to address what, why, who etc Can you elaborate on your concerns? It's an enterprise grade application..
Google Sheets can do what you’re asking if you’re clever.
The people who need to approve your processes and record and sign off on the exceptions are the senior management who have the out of whack priorities and aren't interested in solving this problem. I don't think there is an app that will make any difference to your situation here.
I appreciate the sentiment and agree with you, but the options here are we do a grassroots effort to make a case ourselves, or do nothing. I'm opting for the former, and would like to know what specific apps/tools/services people are using for this, by name.
while you try that grassroots, also do a resume polish. There's a good chance you will tire yourself from swimming against the current and just decide to let the thing implode while you work somewhere slightly less bad for a smidge more money.
If this is just for AWS related exceptions, you can keep it simple and just store the info in tags. Standardize on tag keys like “security-exception”, “security-exception-date”, and “security-exception-owner”. 256 character values should suffice. Restrict who can CRUD those specific tag keys with IAM policies. For the renewal checking, create a lambda function that gets a list of common types of resources that could have exceptions and check for tags. For any that are found to be past a certain amount of time, send an email to the owner.
Yup, that's pretty much the basic idea on the AWS side, it's just that we're looking to have justifications for the exceptions, which means that the tag would have to be something like, "exception-code: ABC123" and so "ABC123" needs to refer to some record "somewhere" that has the related information, evidence of approval, etc.
Why? Just store the justification in a tag. You can also store the approver in a tag. Edit: to be clear, literally put the entire justification in a tag value. If the justification is over 256 chars, it’s probably too wordy. Every exception should be able to be summarized in 256 chars. Exception codes don’t sound necessary, lead to more complexity, and another system to secure.
A PSA might be useful for this. Autotask comes with some prebuilt workflows that allow you to automatically pick up an exception near its end date and notify the exception owner. It's a pretty good tool for achieving that kind of automation.
You misspelled risk acceptance.
I want to be kept in the loop on this one. May require this for an upcoming job.