InfoSec Compliance & AI Governance For over 20 years, DISC InfoSec has been a trusted voice for cybersecurity professionals—sharing practical insights, compliance strategies, and AI governance guidance to help you stay informed, connected, and secure in a rapidly evolving landscape.
Ismael Valenzuela (McAfee/SANS) and Vicente Diaz (Threat Intel Strategist at Virustotal)
SANS Institute‘s #SEC530 course co-authored by Ismael Valenzuela (@aboutsecurity), providing students access to VTIntelligence to help them make TTPs actionable.
Lesson 1: Take stock of identities and lock them down
When it comes to data protection, security and compliance, organizations must keep the potential technology risk within acceptable limits, which means mobilizing efforts to identify data lakes and applications where personally identifiable information (PII) and other sensitive information is stored. Organizations should then use digital transformation as the catalyst to lock those applications down with the proper controls to prevent the unauthorized use of data and use analytics to gain visibility into the management-sensitive data.
The key to any data privacy compliance is proper data protection because under these laws, consumers retain the right to deny and revoke the collection of their data. The first step in any plan around compliance is to have a basic understanding of whose data you have, where it is, and who has access to it. This principle is the foundation of identity management and governance.
Provides a process and roadmap for any company to develop its unified Cybersecurity and Cyber Resiliency strategies. It demonstrates a methodology for companies to combine their disassociated efforts into one corporate plan with buy-in from senior management that will efficiently utilize resources, target high risk threats, and evaluate risk assessment methodologies and the efficacy of resultant risk mitigations. The book discusses all the steps required from conception of the plan from preplanning (mission/vision, principles, strategic objectives, new initiatives derivation), project management directives, cyber threat and vulnerability analysis, cyber risk and controls assessment to reporting and measurement techniques for plan success and overall strategic plan performance. In addition, a methodology is presented to aid in new initiative selection for the following year by identifying all relevant inputs.
“This is the tour de force on designing, implementing and maintaining a modern cyber security and resiliency program. This book is a necessity for all information security and resiliency professionals.” – Howard Taylor, CISO of Radware
OUTLINE
This book lays out a systematic process for developing corporate strategy in the area of cyber (meaning IT) security and resilience.
Here are five signs that a virtual CISO may be right for your organization.
1. You have a lot to protect
Companies produce more data than ever, and keeping track of it all is the first step to securing it. A virtual CISO can identify what data needs to be protected and determine the negative impact that compromised data can have, whether that impact is regulatory, financial or reputational.
2. Your organization is complex
Risk increases with employee count, but there are many additional factors that contribute to an organization’s complexity: the number of departments, offices and geographies; how data is used and shared; the distribution of architecture; and the life cycle of applications, data and the technology stack.
A virtual CISO offers an unbiased, objective view, and can sort out the complexity of a company’s IT architecture, applications and services. They can also determine how plans for the future add complexity, identify and account for the corresponding risk, and recommend security measures that will scale to support future demand.
3. Your attack surface is broad
For many organizations, potential vulnerabilities, especially those that share a great deal of data within the organization, may not be obvious at first glance. Virtual CISOs can identify both internal and external threats, determine their probability and quantify the impact they could have on your organization. And at a more granular level, they can determine if those same threats are applicable to competitors, which can help maintain competitiveness within your market.
4. Your industry is highly regulated
Organizations in regulated industries like healthcare, finance, energy/power and insurance will have data that is more valuable, which could make them a bigger target for bad actors. Exposure is even more of a concern due to potential noncompliance. Virtual CISOs bring a wealth of expertise on regulatory standards. They can implement processes to maintain compliance and offer recommendations based on updates to applicable rules and regulations.
5. Your risk tolerance is low
An organization without a great deal of sensitive data may have a much greater tolerance for risk than a healthcare provider or a bank, but an honest assessment is important in determining how much risk each organization should accept. A virtual CISO can coordinate efforts to examine perceived and actual risk, identify critical vulnerabilities and provide a better picture of risk exposure that can inform future decisions.
Cybersecurity is growing more complex, and organizations of all sizes, especially those in regulated industries, require a proven security specialist who can address the aforementioned challenges and ensure that technology and processes are in place to mitigate security risks.
Cyber Risk Quantification (CRQ) is now viewed as a core pillar of any effective Integrated Risk Management program. This short explainer video walks you through and gives you a glimpse into your future as a top tier cyber risk management organization.
Enough about culture and on to DevSecOps. What kind of culture allows it to thrive?
An important aspect is having a better understanding of the motivators of and detractors in each element. I won’t review those here because they are covered well in this article: https://www.stackrox.com/post/2021/02/devops-vs-devsecops-heres-how-they-fit-together/ But I will say that this topic brings to mind the Stephen Covey quote, “Seek first to understand, then to be understood.”
Another cultural aspect is that the model requires people to “fail fast.” Failure must be allowed. It’s not the kind of failure that leads to company ruin, though it may might be personally embarrassing. You know that main network cable that leads to your office, the one with the sign “Do not unplug!”? I’m the guy who accidentally unplugged it. I’m also the guy who returned a laptop without an RMA: it got lost on the return trip, so we never got our money back. I’m the one who worded something poorly in a policy and was glad that someone caught it before it went out. People make mistakes. The allowance of failure will actually lead to encouraging people to fail, born out of the idea that the more they do, the more they’ll fail AND succeed.
The culture also has to engender the attitude of “a failure is an event, not a person.” As I referenced earlier – we’re not talking about allowing failures that destroy companies and reputations; I’m talking about failures such as “Oops! I deleted that section of code because I didn’t think it was needed. I’ll get it back ASAP.”
This kind of culture leads, not to diminishing returns, but to cohesion in the team and growth in technical acumen. Do those failures get pointed out and documented? Of course – the team doesn’t really want to spend another 4 hours on another night correcting the same mistake. The person doesn’t get called out, but the failure gets pointed out.
The collaborators must be able to expose a vulnerability, have it prioritised, and get it fixed. No naming and shaming, because the goal is not a person’s desire never to fail, but to provide a secure and well-working product.
DevSecOps culture also lends itself to letting those doing the work determine what works best for them, which empowers them to be better professionals. Over time, the team notices patterns in failures and successes, and knows best what product or service would overcome those failures and automate successes.
There needs to be ample maker time, so DevSecOps needs to be free from an interrupt-driven culture. There’s a creative aspect to DevSecOps that requires time to think. Anyone in the arts knows that about the sliding scale of concentration (though they may not call it that). On one end is complete focus on a task, but this extreme focus removes the emotional element. On the other end is the emotional scale, but this extreme leaves out the technical part. Toward the middle is the proper mindset, where there’s a free-thinking and open sensitivity required for being creative, in addition to keeping the boundaries of the techniques and protocols, provided by business requirements, customer demand, etc.
Perhaps you aren’t currently part of a corporate culture for proper DevSecOps to thrive, for whatever reason (e.g., current management attitude, a change in leadership). You could work on creating a subculture. You might have a co-worker with whom you can work to make improvements while not negatively impacting the current speed of production. Or you have some leeway to introduce a tool that can help slightly.
Technology changes frequently, and those making things happen need to stay up-do-date with training. Embrace it, incorporate it as part of the incentives, make it part of the day, make it happen.
DevSecOps are people, and they need rest. There’s only so much and so fast that people can work, and that’s why we use technology. In DevSecOps, technology does not replace people, but enables them to perform their various duties at the speed of light.
Metrics have to be as concrete as possible. How does management determine if personnel are doing things right and doing the right things? Judging success by hearsay and feeling is never a rational metric
Regardless of what else it’s called – DevOps with a security focus, DevOpsSec, Secure DevOps – the end result is to have Development, Operations, and Security work together to iteratively create a good and secure product that is delivered timely. When the culture adopts these elements, DevSecOps will flourish.
We’ve recently witnessed large companies that were hit with major data breaches and cybersecurity incidents point the finger of blame at the lowest hanging fruit – their employees. While it’s understood that employees have a certain level of accountability when it comes to their role in the organization’s broader security strategy, it’s up to company leadership to arm them with the resources and knowledge to effectively thwart cyber threats.
With 90% of security incidents stemming from human error, a culture strong in security awareness is no longer a nice-to-have, it is a top priority and an absolute must across all organizations, regardless of their size or industry. Businesses who change risky employee behavior methodically and effectively through personalized, timely, and relevant learning will see an improvement to their overall security posture and a reduction in the number of security incidents.
Personalization is key
Cyber threats today have become increasingly sophisticated and more personalized. Therefore, it stands to reason that the training and coaching offered to employees needs to meet the same level of personalization in order to effectively combat these threats and change risky habits and behaviors over time.
We’re sure you’ve heard of OpenSSL, and even if you aren’t a coder yourself, you’ve almost certainly used it.
OpenSSL is one of the most popular open-source cryptography libraries out there, and lots of well-known products rely on it, especially on Linux, which doesn’t have a standard, built-in encryption toolkit of its own.
Even on Windows and macOS, which do have encryption toolkits built into their distributions, you may have software installed that includes and uses OpenSSL instead of the operating system’s standard cryptographic libraries.
As its name suggests, OpenSSL is very commonly used for supporting network-based encryption using TLS, which is the contemporary name for what used to be called SSL.
TLS, or transport layer security, is what puts the padlock into your browser, and it’s probably what encrypts your email in transit these days, along with protecting many other online communications initiated by your computer.
Threat actors hacked the official Git server of the PHP programming language and pushed unauthorized updates to insert a backdoor into the source code.
Unknown attackers hacked the official Git server of the PHP programming language and pushed unauthorized updates to insert a backdoor into the source code.
On March 28, the attackers pushed two commits to the “php-src” repository hosted on the git.php.net server, they used the accounts of Rasmus Lerdorf, the PHP’s author, and Jetbrains developer Nikita Popov.
Maintainers of the project are investigating the supply chain attacks, experts believe attackers have compromised the git.php.net server.
“We don’t yet know how exactly this happened, but everything points towards a compromise of the git.php.net server (rather than a compromise of an individual git account).” wrote Popov. “While investigation is still underway, we have decided that maintaining our own git infrastructure is an unnecessary security risk, and that we will discontinue the git.php.net server. Instead, the repositories on GitHub, which were previously only mirrors, will become canonical. This means that changes should be pushed directly to GitHub rather than to git.php.net.”
The maintainers of the PHP reverted the changes and are reviewing the repositories to detect any other evidence of compromise beyond the two referenced commits.
In the future, in order to access the repositories, users will now need to be part of the php organization on GitHub and their account will have 2FA enabled. Adopting this new configuration it is possible to merge pull requests directly from the GitHub web interface.
At this time, it is not immediately clear if the backdoor was downloaded and distributed by other parties before the malicious commits were detected.
Documentation is a crucial part of any ISO 27001 implementation project, and one of the most important documents you need to complete is the SoA (Statement of Applicability).
In this blog, we explain what an SoA is, why it’s important and how to produce one.
What is a Statement of Applicability?
An SoA summarises your organisation’s position on each of the 114 information security controls outlined in Annex A of ISO 27001.
Clause 6.1.3 of the Standard states an SoA must:
Identify which controls an organisation has selected to tackle identified risks;
Explain why these have been selected;
State whether or not the organisation has implemented the controls; and
Explain why any controls have been omitted.
Every control should have its own entry, and in cases where the control has been selected, the SoA should link to relevant documentation about its implementation.
Which controls do you need to implement?
Organisations are only required to implement controls that are appropriate to the risks they face. They should determine which controls apply to them by conducting an ISO 27001 gap analysis and risk assessment.
These processes help organisations identify the risks they face, which they can match to the relevant control.
Annex A provides a useful outline of each control. Still, you’ll probably need something more in-depth when it comes to the implementation process. That’s where ISO 27002 comes in. It’s a supplementary standard in the ISO 27000 series, providing a detailed overview of information security controls.
ISO 27002 provides detailed information on each control, explaining how each one works and providing advice on how to implement it.
The SoA is a useful document for everyday operational use because it provides comprehensive coverage of your organisation’s information security measures.
You can refer to it to understand how and why your organisation is tackling certain risks and accepting others.
This is especially important when ensuring continual improvement within your organisation. You can assess whether the controls you’ve implemented are working as intended and assess whether other controls might be more suitable.
Likewise, you can review why you chose to accept risks and determine whether the threat landscape has increased significantly enough to warrant a change.
An SoA also has significant regulatory consequences. If you are investigated for a data breach, you can use the document to demonstrate that your defences were the result of an ISO 27001-compliant risk assessment.
Completing the Statement of Applicability
Completing the SoA can seem like a daunting task, but there are a few things you can do to simplify the process.
For a start, you should consider delegating each part of the process to the relevant person. You can ask someone in the HR department to provide information regarding the way they process personal data, and do the same for IT, marketing and so on.
Breaking it down this way saves time – as you aren’t relying on one person or a small team to understand every part of your organisation. It also makes it easier to understand specific issues that your business faces.
Another way to simplify the SoA is by consulting ISO 27002. This is a supplementary standard that focuses on the information security controls that organisations might choose to implement.
These controls are listed in Annex A of ISO 27001, but whereas that document simply outlines each control in one or two sentences, ISO 27002 dedicates an average of one page per control.
Finally, you should consider pooling together the documents you’ve created as part of your ISO 27001 implementation project – namely, the inventory of information assets, the risk assessment, the risk treatment plan.
Each of these documents provides a partial picture of your information security practices, but when you consider them altogether, you get a much clearer picture, which you can use to inform your SoA.
Save time writing your Statement of Applicability
Those looking for help creating their SoA should take a look at our ISO 27001 Toolkit.
The toolkit includes:
A complete set of easy-to-use, customisable and fully ISO 27001-compliant documentation templates that will save you time and money;
Simple dashboards and gap analysis tools to ensure complete coverage of the Standard; and
Direction and guidance from expert ISO 27001 practitioners.
A research from Secure Code Warrior has revealed an attitudinal shift in the software development industry, with organizations bucking traditional practices for DevOps and Secure DevOps.
The global survey of professional developers and their managers found 70% of organizations recognize the importance of secure coding practices, with results indicating an industry-wide shift from reaction to prevention is underway.
Dr. Matias Madou, CTO at Secure Code Warrior, said, “We are seeing a fundamental shift in mindsets across the world, as the industry slowly moves from reactive, band-aid solutions rolled out after a breach, to the proactive and human-led practice of writing quality software that is intrinsically free from vulnerabilities right from the very first keystroke.”
“This research shows that ‘secure code’ is becoming synonymous with ‘quality code’ within software development, and security is becoming the responsibility of development teams and leaders—not just AppSec professionals,” he said.
Secure coding practices
Reactive practices like using tools on deployed applications and manually reviewing code for vulnerabilities were the top two practices respondents associated with coding securely.
However, a proactive shift in mindset was evidenced across the globe, with 55% of the developers surveyed also recognising secure coding as the active, ongoing practice of writing software protected from vulnerabilities.
Regular Naked Security readers will know we’re huge fans of Alan Turing OBE FRS.
He was chosen in 2019 to be the scientist featured on the next issue of the Bank of England’s biggest publicly available banknote, the bullseye, more properly Fifty Pounds Sterling.
(It’s called a bullseye because that’s the tiny, innermost circle on a dartboard, also known as double-25, that’s worth 2×25 = 50 points if you hit it.)
Turing beat out an impressive list of competitors, including STEM visionaries and pioneers such as Mary Denning (first to unravel the paleontological mysteries of what is now known as Dorset’s Jurassic Coast), Rosalind Franklin (who unlocked the structure of DNA before dying young and largely unrecognised), and the nineteenth-century computer hacking duo of Ada Lovelace and Charles Babbage.
The Universal Computing Machine
Turing was the groundbreaking computer scientist who first codified the concept of a “universal computing machine”, way back in 1936.
At that time, and indeed for many years afterwards, all computing devices then in existence could typically solve only one specific variant of one specific problem.
They would need rebuilding, not merely “reinstructing” or “reprogramming”, to take on other problems.
Turing showed, if you will pardon our sweeping simplification, that if you could build a computing device (what we now call a Turing machine) that could perform a certain specific but simple set of fundamental operations, then you could, in theory, program that device to do any sort of computation you wanted.
The device would remain the same; only the input to the device, which Turing called the “tape”, which started off with what we’d now call a “program” encoded onto it, would need to be changed.
So you could program the same device to be an adding machine, a subtracting machine, or a multiplying machine.
You could compute numerical sequences such as mathematical tables to any desired precision or length.
You could even, given enough time, enough space, enough tape and a suitably agreed system of encoding, produce all possible alphabetic sequences of any length…
…and therefore ultimately, like the proverbially infinite number of monkeys working at an infinite number of typewriters, reproduce the complete works of William Shakespeare.
If you type in securityboulevard.com, Chrome version 90 will send you directly to the secure version of the site. Surprisingly, that’s not what it currently does—instead, Google’s web browser relies on the insecure site to silently redirect you.
That’s slow. And it’s a privacy problem, potentially. This seemingly unimportant change could have a big—if unseen—impact.
So long, cleartext web. In today’s SB Blogwatch, we hardly knew ye.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Making breakfast.
Lack of security is currently the norm in Chrome. … The same is true in other browsers. … This made sense in the past when most websites had not implemented support for HTTP. … But these days, most of the web pages loaded rely on secure transport. … Among the top 100 websites, 97 of them currently default to HTTPS. [So] when version 90 of Google’s Chrome browser arrives in mid-April, initial website visits will default to a secure HTTPS connection.
The Spectre vulnerability, which stems from vulnerabilities at the CPU design level, has been known for over 3 years now. What’s so interesting about this PoC is that its feasibility for leaking the end-user’s data has now been proven for web applications, meaning that it’s no longer just theoretical.
The vulnerability in affected CPUs has to do with speculative execution, which in certain situations can leave behind observable side-effects and result in data leakage to the attacker. All the attacker needs is a way to execute exploit code in the same executing context as other JavaScript handling sensitive data.
The attacker could use the web supply chain, for instance, presenting itself as a useful library so that victims voluntarily add it to their webpages, or deliberately compromise a third-party library as a way to attack websites that use it. Another vehicle would be to find an injection vulnerability on the website and combine that with the Spectre exploit.
Regardless of the method, the list of victims would be long, as Spectre exploits the JavaScript engines of browsers across several different operating systems, processor architectures, and hardware generations.