2

I was in a recent dispute with the CIO regarding this (I work as an InfoSec Officer).

There was an issue when one of our devs published erroneous code in production due to user error (copy-paste sort of error).

This resulted in faulty software behaviour, particularly in displaying faulty financial information to customers.

The CIO asked me to take over this issue as this can be considered a violation of Integrity. On the other hand, to me this seems more like a Quality Control issue, however I cannot argue on the Integrity bit, plus this could easily be part of our Information Security Risk Assessment.

I would welcome your ideas and views on this.

Improve this question
0

2 Answers 2

Reset to default
1

Yes, it is a QC issue. Yes, it is an infosec issue. Where to draw the lines of responsibility depends on your orgnisation and where and how they want to draw the lines and empower people to affect change.

In some organisations, physical security falls under the InfoSec officer (the CISSP used to include fire safety and door lock mechanisms as part of the body of knowledge). If that's where the org wants to place that level of oversight and authority, then great. As long as they are resourced in accordance with the responsibility they are tasked with.

I see no need for a dispute. If the CIO wants this to be under your charge, then accept it and map out the resources you need to deal with this role. InfoSec should be embedded into more functions in more orgs.

The worst case scenario is that the CIO does not see the value in any change or oversight at all and the problem continues unchecked (I've seen that happen too many times). The fact that the CIO wants this problem handled is a good thing! Your discussions should center around the how not the who.

Improve this answer
3
  • I'd add that there's a reason that he wants Information Security looking at this and the CIO may not be in a position to divulge that information. We all get asked by our bosses to do things that are technically not our job; how we respond to them determines our path in the company and careers.
    – baldPrussian
    Jan 24, 2018 at 14:01
  • @baldPrussian I do not think the reason is opaque. Where and who manages the processes to prevent it from happening again is up to management. InfoSec is perfectly valid.
    – schroeder ♦
    Jan 24, 2018 at 14:09
  • In reality, the organisational structure in our firm is not properly defined, I currently work under the CIO's supervision and our QC is next to nothing. However I wanted to keep the scope of the question broad so I can get an answer such as this.
    – jonna_983
    Jan 25, 2018 at 8:40
1

I agree it's not really infosec, you're of course not staffed to review code yourself, or do QC yourself. However, your skills and position should be fine to address the issue at a management level. I would focus on the controls and let the CIO know you're going down this road. Keep the investigation details confidential.

How did the code pass peer review? Can they demonstrate that peer review (or your similar processes) were documented, people were trained and the processes followed? Are they regularly asking their neighbour to "+1 me!" without a culture of actually checking? Did dev have a post-mortem of the failure? Do they have suggestions or new processes to prevent this from happening again?

Did QC have an automated test? Why or why not? Did it pick up the bug? Why was it not part of their test coverage. Will be be added to their test coverage? When?

Check that the audit logs match the story of the developers and QC. If the stories don't match, ask more questions.

At the end of it all, you should have a report with recommendations and findings. The CIO can call a review meeting. I would privately ask the CIO if you want to put fear into the leadership for this "breach". If you're not careful about your documentation and curbing your language around your findings, of course your peers will hate you forever, but that's a dark side of internal investiigations in infosec.

IMHO, QC leadership should be asking these questions, but given they haven't stood up to take the issue, the CIO might not have confidence in that leadership.

All of this information should be retained as it may be useful as evidence of your dilligence in investigating a security issue in code. Review it with the CIO, clean up the excessive detail, add your remediation activities and add it to your records.

Improve this answer
2
  • I think the takeaway here is: this itself is not an issue of information security, but the processes involved seem to not work properly and might produce other issues, that then can be security related.
    – Tom K.
    Jan 24, 2018 at 11:48
  • I wouldn't say that QC and Developer processes are not an issue of information security, but more narrowly, it's QC's job to execute, or Dev's job to execute. If you're representing infosec at your company, you're signing off that the SDLC contains controls like peer-review, automated tests, etc. A bug like this may be an indication that something is wrong. QC or Dev is ultimately responsible to fix it, but Infosec should have no qualms about getting involved in the investigation.
    – mgjk
    Jan 25, 2018 at 10:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .