What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2022-08-06 10:46:21 | CISO workshop slides (lien direct) | A glossy, nicely-constructed and detailed PowerPoint slide deck by Microsoft Security caught my beady this morning. The title 'CISO Workshop: Security Program and Strategy' with 'Your Name Here' suggests it might be a template for use in a workshop/course bringing CISOs up to speed on the governance, strategic and architectural aspects of information security, but in fact given the amount of technical detail, it appears to be aimed at informing IT/technology managers about IT or cybersecurity, specifically. Maybe it is intended for newly-appointed CISOs or more junior managers who aspire to be CISOs, helping them clamber up the pyramid (slide 87 of 142): | Malware Vulnerability Threat Patching Guideline Medical Cloud | Uber APT 38 APT 37 APT 28 APT 19 APT 15 APT 10 APT 34 Guam | |
|
2022-08-01 14:00:00 | Fragility is ... (lien direct) |  ... the arch-enemy - not the polar opposite - of resilience ... a natural consequence of complexity and dependence... when threat meets vulnerability exceeding control... not knowing whether, how and when it will break... being unable/unwilling/afraid to rely on it ... untrustworthy, inadequate controls ... pushing too far, too fast, too hard... exceeding the breaking strain... passing the point of no return... an engineering challenge ... inevitable at some point... hanging on by a thread ... often revealed too late... a propensity to failure ... being on a knife-edge... going over the brink... obvious in hindsight... being a snowflake... a smashed mirror... beyond the pale ... a broken vase... a cracked egg... a step too far... uncertainty... snap!... |
Vulnerability Threat | ★★ | |
|
2022-05-21 15:49:50 | Responsible disclosure - another new policy (lien direct) |  We have just completed and released another topic-specific information security policy template, covering responsible disclosure (of vulnerabilities, mostly).The policy encourages people to report any vulnerabilities or other information security issues they discover with the organisation's IT systems, networks, processes and people. Management undertakes to investigate and address reports using a risk-based approach, reducing the time and effort required for spurious or trivial issues, while ensuring that more significant matters are prioritised. The policy distinguishes authorised from unauthorised security testing, and touches on ethical aspects such as hacking and premature disclosure.It allows for reports to be made or escalated to Internal Audit, acting as a trustworthy, independent function, competent to undertake investigations dispassionately. This is a relief-valve for potentially sensitive or troublesome reports where the reporter is dubious of receiving fair, prompt treatment through the normal reporting mechanism - for instance, reporting on peers or managers.It is primarily intended as an internal/corporate security policy applicable to workers ... but can be used as the basis for something to be published on your website, aimed at 'security researchers' and ethical hackers out there. There are notes about this at the end of the template. To be honest, there are plenty of free examples on the web but few if any are policies covering vulnerability disclosure by workers.All that in just 3 pages, available as an MS Word document for $20 from SecAware.com.I am working on another 2 new topic-specific policies as and when I get the time. Paradoxically, it takes me longer to prepare succcinct policy templates than, say, guidelines or awareness briefings. I have to condense the topic down to its essentials without neglecting anything important. After a fair bit of research and thinking about what those essentials are, the actual drafting is fairly quick, despite the formalities. Preparing new product pages and uploading the templates plus product images then takes a while, especially for policies that relate to several others in the suite - which most do these days as the SecAware policy suite has expanded and matured. As far as I know, SecAware has the broadest coverage of any info/cybersec policy suite on the market.... Talking of which, I plan to package all the topic-specific policies together as a bulk deal before long. Having written them all, I know the suite is internally consistent in terms of the writing style, formatting, approach, coverage and level. It's also externally consistent in the sense of incorporating good security practices from the ISO27k and other standards. |
Vulnerability | ||
|
2022-04-23 18:05:53 | Topic-specific policy 10/11: management of technical vulnerabilities (lien direct) | With respect to whoever crafted the wording of the 10th topic-specific example policy for ISO/IEC 27002:2022, "management of technical vulnerabilities" is the kind of phrase that speaks volumes to [some, switched-on, security-aware] IT pro's ... and leaves ord'nry folk perplexed, befuddled and nonplussed. In this case, that may be appropriate if it aligns with the intended audience for the policy, perhaps not if the policy needs to be read, understood and complied with by, say, workers in general, for whom "Patching" is arguably a more apt and widely-known term.So, do you need to tell workers to keep their IT systems, smartphones and IoT things up to date with security patches? If so, before launching into the policy development process, think very carefully about the title, content and style of your policy - plus the associated procedures, guidelines, awareness and training materials, help-desk scripts or whatever you decide is necessary to achieve your information risk management objectives in this regard (more on that below).Hinson tip: what are your information risk management objectives in this regard (concerning 'technical vulnerabilities' ... or whatever aspect/s you believe need addressing)? What information risks are you facing, how significant are they (relative to other things on your plate) and how do you intend to treat them? Seriously, think about it. Talk it through with your peers and professional colleagues. Draft a cunning treatment plan for this particular subset of information risks, discuss it with management and refine it. Lather, rinse, repeat until you achieve consensus (or wear down the blockers and negotiate a fragile settlement), and finally you are primed to craft your policy.Once more, we have your starter-for-ten, a generic patching policy template designed to help get you smartly off the starting blocks: While we don't presently offer a policy template on vulnerability disclosures (something worth adding to our to-do list, maybe?), we do have others that are to some extent relevant to this topic, for instance on change and configuration management and information systems security. I'll pick up on that point at the end of this blog series.Aside f |
Vulnerability | ||
|
2022-04-22 09:26:38 | Professional services - preliminaries (lien direct) | Yesterday I proposed a guideline on the information risk, security and privacy aspects of professional services. I introduced a simplistic 3-phase model for the business relationship through which one or more professional services assignments are delivered and consumed.  Today, I'm exploring the preliminary phase.Before professional services are delivered, client and provider form a business relationship. They determine the professional services required and offered, and of course negotiate the commercial arrangements. They also have the opportunity to decide how the services are to be provided, and how both the assignment/s and the business relationship are to be managed.Contracting is an important control in its own right with significant information and commercial risks associated. The contract may for instance: Be inappropriate for either organisation, the relationship and/or the professional service/s; Be informal, undocumented, invalid and hence unenforceable;Bypass or shortcut due process;Be uneconomic for either party; Be unfair, biased and perhaps unethical;Lead to problems if an assignment fails or the whole relationship turns sour, perhaps as a result of an incident. Contracting is a chance for both organisations to think forward, discuss and agree the governance, management, compliance, security/privacy, control and assurance needed for the remainder of the professional services lifecycle (both phases!). It may be infeasible, later on, to modify the terms or specify additional requirements and the associated arrangements for integrity, confidentiality, incident management etc., especially if relationship issues arise.Also at this stage, client and provider conduct some form of due diligence checks on each other, exploring factors such as solvency, competence, qualifications, certifications and reputations. The manner in which both parties participate in this phase can be a valuable predictive indicator - a big clue as to how things are likely to pan out later e.g.:Appreciation of the each party's capabilities and concerns, plus their common interests in making a commercial success of the planned assignment/s and the business relationship as a whol |
Vulnerability Guideline | ||
|
2021-10-22 16:00:00 | Topic-specific example 10/11: management of technical vulnerabilities (lien direct) | With respect to whoever crafted the wording of the 10th topic-specific example policy for ISO/IEC 27002:2022, "management of technical vulnerabilities" is the kind of phrase that speaks volumes to [some, switched-on, security-aware] IT pro's ... and leaves ord'nry folk perplexed, befuddled and nonplussed. In this case, that may be appropriate if it aligns with the intended audience for the policy, perhaps not if the policy needs to be read, understood and complied with by, say, workers in general, for whom "Patching" is arguably a more apt and widely-known term.So, do you need to tell workers to keep their IT systems, smartphones and IoT things up to date with security patches? If so, before launching into the policy development process, think very carefully about the title, content and style of your policy - plus the associated procedures, guidelines, awareness and training materials, help-desk scripts or whatever you decide is necessary to achieve your information risk management objectives in this regard (more on that below).Hinson tip: what are your information risk management objectives in this regard (concerning 'technical vulnerabilities' ... or whatever aspect/s you believe need addressing)? What information risks are you facing, how significant are they (relative to other things on your plate) and how do you intend to treat them? Seriously, think about it. Talk it through with your peers and professional colleagues. Draft a cunning treatment plan for this particular subset of information risks, discuss it with management and refine it. Lather, rinse, repeat until you achieve consensus (or wear down the blockers and negotiate a fragile settlement), and finally you are primed to craft your policy.Once more, we have your starter-for-ten, a generic patching policy template designed to help get you smartly off the starting blocks:While we don't presently offer a policy template on vulnerability disclosures (something worth adding to our to-do list, maybe?), we do have others that are to some extent relevant to this topic, for instance on change and configuration management and information systems security. I'll pick up on that point at the end of this blog series.Aside f |
Vulnerability | ||
|
2021-10-07 14:24:08 | An important lesson from the Farcebook Fiasco 2021 (lien direct) |  I gather from friends and the news media that there was an unplanned outage earlier this week at Facebook. I'm told that Facebook is a fairly popular social media platform - some have said addictive. As you can no doubt tell, I don't see the attraction and I'm definitely not hooked. If it weren't for the brouhaha, I wouldn't have even noticed.I understand the outage was caused by a technical issue in the network - something to do with the BGP configuration. I'm not particularly interested in, and probably wouldn't even understand, the details. The self same issue locked Facebook's IT administrators out of their own systems, leaving them cut off and unable to address/reverse/fix the issue for several hours, causing mild panic and a little outrage among its users, customers and other stakeholders. The same issue took down related websites too. Doubtless the admins were stressed out, possibly frantic, while their managers were unimpressed.I'm bringing it up here to point out a lesson for all other organisations, not just those reliant on remote system admin. If the network access is broken and unavailable, for whatever reason, remote admin is also broken and unavailable. That's screamingly obvious to all of us now with 20/20 hindsight thanks to the Farcebook Fiasco, and clearly an issue worth addressing by organisations that use and rely on remote system/network/app/IT admin, of which I'm sure there are many. I'm told that cloud is in, and the Interwebs are quite useful.Less obviously, the incident a neat reminder that foresight is even more valuable, more specifically information risk management. Regardless of the nature of the technical issue and preceding activities that sparked the outage, single points of failure are a class of vulnerability well worth identifying and addressing, especially for anything important. The solution is known as defence-in-depth, an approach that is universally employed by all living organisms - except, it seems, Facebook IT people. As to how they might have mitigated the risks, there are several possible means of administering network systems aside from remote access through the same network. I'm not even going to attempt to list them. Go ahead, Google if you care. There are myriad ways that information services may be interrupted, some deliberate/intentional, many accidental, inadvertent or due to natural causes. It's simply impracticable to attempt to identify and deal with them all, individually, hence the value of a much more generalised approach to specifying, achieving, maintaining and being confident in the required availability. It's called resilience, a natural complement to contingency planning, both of which are parts of the nebulous approach called business continuity management. That's more than enough waffle |
Vulnerability | ||
|
2020-09-04 14:26:51 | NBlog Sept 4 - standardising ISMS data interfaces (lien direct) |  We've been chatting on the ISO27k Forum lately about using various IT systems to support ISO27k ISMSs. This morning, in response to someone saying that a particular tool which had been recommended did not work for them, Simon Day made the point that "Each organisation trying to implement an ISMS will find it's own way based on their requirements."Having surveyed the market for ISMS products recently, I followed-up with my usual blurb about organisations having different information risks and business situations, hence their requirements in this area are bound to differ, and in fact vary dynamically (in part because organisations mature as they gain experience with their ISMS: their needs change). The need for flexibility is why the ISO27k standards are so vague (essentially: figure out your own requirements by identifying and evaluating your information risks using the defined governance structure - the ISMS itself), rather than explicitly demanding particular security controls (as happens with PCI-DSS). ISO27k is designed to apply to any organisation. That thought sparked a creative idea that I've been contemplating ever since: wouldn't it be wonderful if there was a standard for the data formats allowing us to migrate easily between IT systems supporting ISO27k ISMSs?I'm idly thinking about a standard file format with which to specify information risks (threats, vulnerabilities, impacts and probabilities), controls, policies, procedures, metrics, objectives etc. - maybe an XML schema with specified field names and (where applicable) enumerated lists of values.Aside from migrating between ISMS IT support systems and services, standard data formats would facilitate data sharing between application systems, services or sub-functions (e.g. for vulnerability management, incident management and information risk management), and between departments or even organisations (e.g. insurance companies, auditors and advisors and their clients and partners).Perhaps we should develop an outline specification and propose such a standard to ISO/IEC JTC1 SC 27. A New W |
Tool Vulnerability | ||
|
2020-09-04 14:22:25 | NBlog July 15 - ISO27k ISMS products (lien direct) |  Having drafted a generic requirement specification for systems supporting an ISO27k ISMS, I'm slowly trawling the Web for products in the hope of finding apps, templates and services that we would be willing to use ourselves and recommend to our consulting clients.So far I've found about 20 commercial or open-source ISMS systems plus maybe twice that number of risk management systems, plus quite a variety of more focused systems supporting incident management, business continuity, vulnerability management, patch management etc. It's a confusing, sprawling and dynamic market … so I'm also working on a structured evaluation process that will help us pick out gems from the stones on offer, depending on our own and our clients' specific needs.Along the way, I've picked up murmurings of discontent from customers saddled with low-quality content supplied with some ISO27k ISMS systems and toolkits. Aside from variation between the products, could it be, I wonder, that some of the products currently on offer are inadequate because customers vary so much in size, complexity, maturity etc. having different expectations or requirements? Could this be a side-effect of ISO27k's intended application to all organizations, resulting it being jack-of-all-trades and master-of-none? We could develop generic content specifically targeting particular market segments or types of organisation ... but instead we've started with the basics that every ISO27k ISMS needs with the intention of offering optional add-ons, giving customers more choice. One of those options is to develop custom materials and support individual customers to implement and optimise their ISMSs using appropriate systems/tools, provided we can convince management of the value of our consultancy services - and that's a tough sell, especially during COVID-19. Doing it all in-house may be a viable option if the organisation has the people with the requisite skills, competencies, knowledge and experience. That seems unlikely if there is no ISMS already in place - catch 22. There's also the matter of the time needed for people to learn the ropes and get up to speed with the ISMS, given all the other things on the go: the longer things drift along, the more the organisation remains subject to information risks that may not be managed effectively.I'm working on other options too. More info to follow. Watch this space. |
Vulnerability | ★★★ | |
|
2020-05-16 17:38:09 | NBlog May 16 - adjusting to the new normal (lien direct) |  According to alert AA20-133A from US-CERT:"The U.S. Government has reported that the following vulnerabilities are being routinely exploited by sophisticated foreign cyber actors in 2020:Malicious cyber actors are increasingly targeting unpatched Virtual Private Network vulnerabilities. An arbitrary code execution vulnerability in Citrix VPN appliances, known as CVE-2019-19781, has been detected in exploits in the wild.An arbitrary file reading vulnerability in Pulse Secure VPN servers, known as CVE-2019-11510, continues to be an attractive target for malicious actors.March 2020 brought an abrupt shift to work-from-home that necessitated, for many organizations, rapid deployment of cloud collaboration services, such as Microsoft Office 365 (O365). Malicious cyber actors are targeting organizations whose hasty deployment of Microsoft O365 may have led to oversights in security configurations and vulnerable to attack.Cybersecurity weaknesses-such as poor employee education on social engineering attacks and a lack of system recovery and contingency plans-have continued to make organizations susceptible to ransomware attacks in 2020."Well whadyaknow?The US government blames "sophisticated foreign cyber actors" - the usual xenophobic, somewhat paranoid and conspiratorial stance towards those filthy rotten foreigners, desperately attacking little old US of A (today's version of reds under beds I guess);"Unpatched" VPNs and insecurely configured Office 365 services are being targeted, implicitly blaming customers for failing to patch and configure the software correctly, blithely ignoring the fact that it was US-based software vendors behind the systems that required patching and configuring to address exploitable vulnerabilities; |
Ransomware Vulnerability Patching |
1
We have: 10 articles.
We have: 10 articles.
To see everything:
Our RSS (filtrered)
