This is the edited chat log from the CSIAC Webinar, “Applying the Top 20 Critical Controls for Risk Assessment“.
Jack R: Is the Return for being compliant a numerical score?
Jack R: Does Risk Management assess the risk of not noticing a risk?
Gavriil M: Very good question Jack.
Jack R: Why use Risk Management rather than the principle of system integrity as in Theory of Constraints?
Jack R: Why not Code Protection as well as Data Protection?
Jack R: How does software get authorized?
Rafael N: I would imagine through your CM process.
Jack R: How often achieves "Continuously"?
Ken S: Need tools to "continuously"!
Richard B: Continuously is defined by the organization.
Rafael N: Also depends on the requirements defined in the specific control
Jack R: Richard, to what degree of efficacy?
Michelle V: Jack, to their level of comfort as it relates to "acceptable risk".
Richard B: My organization says CMP shall be run at least quarterly.
Jack R: How to avoid unauthorized editing of logs?
Richard B: Some of our vendors can do it more often, so they are encouraged to.
Richard B: Jack: permission management
Rafael N: Separate your admins from your auditors and put auditing program in place
Richard B: Rafael, separation of duty is a big part of things.
Richard B: However, the small companies have trouble doing this.
Rafael N: Indeed; at the very least their personnel should have separate accounts for each function
Jack R: Most software systems are not auditable.
Darrell M: Does your registration process also include BYOD? Is there policy that dictates what happens if that (BYOD) is lost?
Richard B: Disagree Jack.
Rafael N: Def disagree
Michelle V: Echoing disagreement
Richard B: Depending on what OS the app runs on, there is the opportunity to integrate into the system auditing.
Rafael N: with "most software systems are not auditable". Most of them have the functionality built in.
Jack R: #10. Why not also Code Recovery Capability?
Richard B: What I find the most challenging is doing and enforcing change management
Michelle V: Change Management built-in with ITSM
Rafael N: Definitely a challenge, Richard
Richard B: Michelle, what does ITSM stand for?
Michelle V: Recovery Capability achievable with use of High Availability Disaster Recovery (HADR)
Rafael N: IT Service Management
Jack R: Richard, Quite so and Change Management is fundamental to Auditing.
Michelle V: ITSM = IT Service Management
Richard B: Thanks for the definition.
Michelle V: My pleasure
Rafael N: Need-to-know is critical and needs to be periodically reviewed
Jack R: If your system is auditable then you have a complete awareness of the system vulnerability surface. I'll bet you don't even know how many latent bugs your deployed system contains.
Rafael N: Software to help implement wireless access control should be purchased and used periodically
Joseph S: A trusted employee is not a control… prison is full of embezzlers that were trusted employees
Richard B: So true Joseph!!!!
Michelle V: Latent bugs should be identified with daily/weekly vulnerability scans
Richard B: Training and assessment needs to be higher than 17 IMHO…
Rafael N: No but implementing an Insider Threat program will help mitigate being taken advantage of by "trusted employees"
Rafael N: trust but verify
Rafael N: There's nothing to train and assess without the first 16
Rafael N: Very true, Michelle
Jack R: Michelle. Pls cite a site where latent bugs are actually known, not just 'should' be known..
Rafael N: What is a "latent bug"?
Richard B: Trying to do the first 16 without properly trained personnel is a waste of time and effort.
Rafael N: True statement, Richard; I was more speaking to a continual training and awareness program
Jack R: A bug that exists after the software is deployed.
Rafael N: All personnel should know their part to play in incident response
Michelle V: Jack, working with DoD, internal sites are almost always aware and informing their stakeholders
Rafael N: Okay well that's where defense-in-depth comes in and mitigation of risk; no system is 100% secure
Ken S: Not just know their part, but also exercise the IRP.
Jack R: #19 How about somebody who stops the vulnerability?
Richard B: reporting of issues outside of your organization is a dangerous issue from a goodwill and liability issue.
Rafael N: Good point, Ken
Jack R: Testing finds only anticipated faults, not all the faults.
Rafael N: Stops the vulnerability or mitigates/removes the vulnerability?
Rafael N: Still have to practice due diligence, Richard
Nathan L: thanks
Gavriil M: Thank you all.
Jack R: Rafael, Stops means remove the vulnerability.
Alan : Cheers!
Rafael N: Gotcha
David : Thanks – good "short & sweet" intro!
Rafael N: That usually means removing the software/hardware, etc. altogether
Rafael N: Most vulnerabilities can only be mitigated
Jack R: What site applies the 20 controls and what degree of invulnerability have they achieved?
Rafael N: Many sites do so but that data may be difficult to find
Rafael N: There's a whole assessment program with an accompanying database/software based on the 20 controls
Gemma A: FISMA Scorecard
CSIAC: Please note: downloading the slides requires registration and login.
CSIAC: You can register to become a CSIAC.org member here: https://www.csiac.org/register/
Jack R: If I score 100% compliance on all 20 controls will my system be invulnerable to cyber actions?
Keith K: Are the 20 controls in priority order (slides 9-10)?
Tiffany G: Jack – no. The point is to limit your risk the best you can by identifying the areas that tend to make you most vulnerable and locking them down.
Rafael N: No, Jack. No such thing as 100% secure. You can only eliminate what risk you can and mitigate the rest.
Richard B: Jack, I don't think that 100% on all controls is realistically attainable.
Rafael N: The goal is to lower risk to an acceptable level
Tiffany G: You can use the controls as a metric within something like the NIST RMF to help you assess and monitor your risk over the lifecycle of the system.
Jack R: It is the 'grey area" of Risks that hackers exploit.
Tiffany G: It's not about compliance/non-compliance, it's about risk management, which is the best we can do.
Gemma A: Jack, the answers is yes…there is never 100% security.
Rafael N: A 100% secure system is one that is powered down and off-line and even then there's physical threat.
Michelle V: There is such a thing known as Zero-Day Exploit.
Richard B: Correct Michelle
Michelle V: Zero-Day meaning it's hot off the presses, something that just came out.
Jack R: The way to achieve 100% of risks is Goldratt's Constraint Theory.
Gemma A: For Zero-Day Exploit you can contact DHS CERT
Jack R: A Zero Day exploit is irrelevant if your system is invulnerable to exploits.
Ken S: are you familiar with the ICS-CERT CSET for assessing your company to the CSC 20
Michelle V: Zero Day is a thing and most relevant. There is no such thing as a system that is invulnerable.
Tiffany G: Systems cannot be made "invulnerable" to exploits.
Ken S: sure they can if you shut them off
Keith K: Ken, you can still exploit an offline system through other technical means.
Gavriil M: yes, Ken. Very good to control the CSC 20 compliance.
Richard B: Ken, if the machine is off, you still have physical security issues.
Michelle V: Static and dynamic analysis as well
Ken S: yep, I can steal your hard drive and then take it to my lab and pull off what I need.
Michelle V: Right, Ken!
Victoria F: How to protect blogs such as WordPress?
Richard B: There is more involved with authorizing software than just analyzing the code/how the software runs.
Jack R: What degree of error does the IT department commit when authorizing your software?
CSIAC: If you would like to ask questions after the webinar. Please ask them here: https://www.csiac.org/podcast/applying-the-20-critical-controls-for-risk-assessment/#respond
Keith K: Need to use machine learning tools to sift through log data and make sense of it. Of course, still need a human to "sanity check" the results.
Michelle V: Tools like Splunk help a lot with log data analysis
Frankie S: Thank you
YouTube Live Stream User: How does an independent test team test for weaknesses in SDLC?
Michelle V: Software Assurance Maturity Model may assist with SDLC
Keith K: Comply to connect–for IoT?
CSIAC: You may be interested in this webinar: https://www.csiac.org/podcast/comply-to-connect-c2c/
Keith K: Cool, thanks CSIAC.
Jack R: Can non-functional testing as is used in hardware, e.g., Intel, be useful in sofware?
Ken S: Michelle Vicotor, splunk or another option is a tool called AristotleInsight.
Michelle V: I'm going to check it out, Ken. Thanks.
Michelle V: Code reviews, yuck! 🙁
Jack R: According to Prof. E. W. Dijkstra "Testing shows the presence, not the absence of bugs."
Michelle V: Penetration testing is also a good way.
Ken S: Code Reviews (automated and non-automated (peer reviews) is crucial for ensuring securely developed software. One of my favorite tools is HP Fortify. They keep the rule packs up to date and matches nicely to our Security Technical Implementation Guides for Application Security and Development.
CSIAC: Design and Development Process for Assured Software – Volume 1 https://www.csiac.org/journal-issue/design-and-development-process-for-assured-software-volume-1/
Jack R: Checking for buffer overflow is non-functional (unless the programmer intended to achieve buffer overflow).
Ken S: Repeat Message: For those that haven't check out the free solution from DHS ICS-CERT Cybersecurity Evaluation Tool (CSET), there is also the CyberResilencyReview (CRR) for comparing your environment to industry standards.
Keith K: Thanks, great talk!
Michelle V: Thanks!
Jack R: Thanks, Andrew. Informative.
Andrew Hurd: Thank you Everyone!
Ken S: good job Andy!!
CSIAC: Register for the next Webinar here: https://www.csiac.org/podcast/software-defined-wan-sd-wan-security-implications-and-design-solutions/
Michelle V: SD-WAN! Yahsss!