I found a security issue some time back, the logging of a long-lived security session token. This token enabled me to access an internal client data service which only checked the validity of the token, not its right to perform the operation on the data I was accessing. We had two types of tokens, managed by the same session token management service, one for clients (the type of token I had found in the logs), and one for trusted internal service accounts. The client service did not care about the difference, and as a consequence I was able to access all client data with my token.
I raised a critical incident, but surprisingly, nobody raised an eyebrow, not even InfoSec. In fact, I was asked why I (little old me) was raising a critical incident. After all, was there a crisis? The incident was closed immediately and I had to instead raise a work item against the relevant team, who only fixed it some weeks later - there were more pressing delivery deadlines to consider.
Then, a week later, I found that some system was logging client passwords when they were changed. This was clearly a critical incident, but I thought twice about raising it. But I did, and boy did that stir the pond! InfoSec were all over it, sending out a flurry of messages to senior management, and the issue was fixed that day.
Yet both incidents were critical. Had I not used my trusty OWASP risk rating methodology spreadsheet to come up with an objective risk assessment for both? You see, the ability to leak all our customer data is just bad as the ability to log in to a few accounts and cause mayhem. We had strict money laundering controls, so financial theft was not the main threat, brand reputation damage was.
So what the hell was going on?
I think the issue is that of understanding security risk. Most people can relate to a password breach, but the other breach was too technical for the average punter. And there was the rub.
I think the answer to this is to establish rules like: if the risk rating is determined objectively to be critical, then it is critical, not: do I think it is critical? Granted, some of the inputs into the OWASP risk rating model are subjective, but they are less technical, and thus harder to get completely wrong.
It has been suggested to me that the business needs to accept the risk, but are they really qualified to do so? Surely it is InfoSec who, on behalf of the business it serves to protect, has to define and enforce SLAs for security risks?
I raised a critical incident, but surprisingly, nobody raised an eyebrow, not even InfoSec. In fact, I was asked why I (little old me) was raising a critical incident. After all, was there a crisis? The incident was closed immediately and I had to instead raise a work item against the relevant team, who only fixed it some weeks later - there were more pressing delivery deadlines to consider.
Then, a week later, I found that some system was logging client passwords when they were changed. This was clearly a critical incident, but I thought twice about raising it. But I did, and boy did that stir the pond! InfoSec were all over it, sending out a flurry of messages to senior management, and the issue was fixed that day.
Yet both incidents were critical. Had I not used my trusty OWASP risk rating methodology spreadsheet to come up with an objective risk assessment for both? You see, the ability to leak all our customer data is just bad as the ability to log in to a few accounts and cause mayhem. We had strict money laundering controls, so financial theft was not the main threat, brand reputation damage was.
So what the hell was going on?
I think the issue is that of understanding security risk. Most people can relate to a password breach, but the other breach was too technical for the average punter. And there was the rub.
I think the answer to this is to establish rules like: if the risk rating is determined objectively to be critical, then it is critical, not: do I think it is critical? Granted, some of the inputs into the OWASP risk rating model are subjective, but they are less technical, and thus harder to get completely wrong.
It has been suggested to me that the business needs to accept the risk, but are they really qualified to do so? Surely it is InfoSec who, on behalf of the business it serves to protect, has to define and enforce SLAs for security risks?