What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2022-11-13 17:50:02 | This blog has been renamed (lien direct) | Wondering why things have gone so quiet lately?The bloggings continue apace over at https://secawareblog.blogspot.com/ Unless you intended to drop out, please update your blogrolls, blog trackers, bookmarks or whatever. | |||
|
2022-08-15 14:00:00 | Control is ... (lien direct) |  ... technical, physical, procedural, legal, social, mechanical, economic, political ...... applied to processes, systems, machines, people, quality ...... a volume knob that goes all the way to 11... automated, semi-automated or manual ... an illusion induced by acquiescence ... preventive, detective or corrective... avoiding or preventing badness... defining and applying rules... what happens in the tower ... an availability challenge ... an engineering solution... local, remote or hybrid ... hitting the sweet spot... keeping within limits... about mitigating risk... a means to an end... binary or analogue... providing direction ... setting boundaries ... negative feedback... power superiority... being in charge... being resilient ... an impression... management |
|||
|
2022-08-09 11:26:08 | The business case for security strategy and architecture (lien direct) |  The business benefits of developing an information security strategy and accompanying security architecture/design include: Being proactive, taking the lead in this area - more puppeteer than puppet; Designing a framework or structure to support the organisation's unique situation and needs; Positioning and guiding the management of information risk and security within other aspect of the organisation's architecture/design e.g. its IT and information architecture (showing information flows, networked systems, databases, services etc.), complementing and supporting various other business strategies and architectures such as cloud first, artificial intelligence, IIoT, big data, new products, new markets ...);Providing a blueprint, mapping-out and clarifying the organisational structure, governance arrangements and accountabilities for information risk and security relative to other parts of the business such as IT, physical security, Risk, legal/compliance, HR, operations, business continuity, knowledge management ...; Defining a coherent sequence or matrix of strategic initiatives (projects, investments, business and technology changes ...) over the next N years, embedding information risk management ever deeper into the fabric of the organisation and strengthening the information security arrangements in various ways (e.g. systematically phasing-out and replacing aged/deprecated security technologies while researching, piloting and then adopting new ones such as blockchain and post-quantum crypto);Driving the development and maturity of the information risk and security management function, covering its priorities, internal structure and external working relationships, governance etc.; Bringing clarity and direction (focus!), reducing complexity and uncertainty associated with myriad 'other options' that are discounted or put on hold;Seizing opportunities to align and support various departments, processes, systems, partners, projects/initiatives, budgets, plans etc., finding and exploiting points of common interest, avoiding awkward conflicts and gaps;Identifying key objectives for information risk and security |
Guideline | ||
|
2022-08-08 14:00:00 | Risk is ... (lien direct) |  ... when threat exploits vulnerability causing impact... tough to measure, express and control... the product of probability and impact... the gap between theory and practice... the root of pessimism and optimism ... the once-in-a-hundred-years event... needing seatbelts and airbags... a hair's breadth from disaster... the possibility of exploitation... mitigated but not eliminated ... a factor to be borne in mind... inevitable in the Real World... not going entirely to plan... outcome =/= prediction ... rarely good, usually bad... rarely bad, usually good... necessary to get ahead |
|||
|
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-08-01 07:08:45 | Webserver problem problem (lien direct) | This cold Winter's Monday morning, we woke to problems accessing our server and websites. The usual turnitoffandonagain approach let us down ... and this time so has downforeveryoneorjustme dotcom: | |||
|
2022-07-26 10:03:09 | Half-a-dozen learning points from a \'27001 certification announcement (lien direct) |  This morning I bumped into a marketing/promotional piece announcing PageProof's certified "compliance" (conformity!) with "ISO 27001" (ISO/IEC 27001!). Naturally, they take the opportunity to mention that information security is an integral part of their products. The promo contrasts SOC2 against '27001 certification, explaining why they chose '27001 to gain some specific advantages such as GDPR compliance - and fair enough. In the US, compliance is A Big Thing. I get that. It occurs to me, though, that there are other, broader advantages to '27001 which the promo could also have mentioned, further valuable benefits of their newly-certified ISMS.I spot at least six general learning points here for organisations currently implementing ISO/IEC 27001: Elaborating on the broad business benefits of '27001 can be a creative and valuable activity in its own right. A well-designed and effective ISMS can achieve way more than protecting the confidentiality, integrity and availability of data, or satisfying GDPR and other compliance obligations. Although PageProof hints at some, it's unclear whether they truly appreciate its full potential but chose not to mention them in this promo. The eventual marketing/promotional value of '27001 certification is worth thinking-through. From the audience's perspective i.e. the organisation's third party stakeholders (particularly customers and prospects, plus partners, owners, regulators and other authorities), what worthwhile differences can they expect as a result of the certification? What are the main points that will truly resonate? How will successful certification be promoted, and how will it change the organisation's ongoing marketing, promotional and advertising activities - plus its operations (in order to satisfy if not exceed the market's expectations)? Rhetorical questions such as these may be raised and discussed at any point, ideally starting early-on in the ISMS design and implementation project, and gradually refined in the run-up to certification. Likewise, what about the internal corporate stakeholders - the managers, staff, contractors, consultants, interns etc.: how will the ISMS implementation project affect the workforce? What changes can they expect? What practical differences will the ISMS make? How can they get involved and help the process along (or at least avoid inadvertenly causing problems)? What are the key messages to be put across through internal communications at all stages of the project?Combining points 1-3 can help clarify the objectives of the ISMS - not just the detailed information risk and security objectives but more generally the business objectives, the rationale for doing all this stuff. What are the anticipated payoffs? Which of those be |
|||
|
2022-07-25 08:51:16 | Resilience is ... (lien direct) |  ... depending on others and being there for them when they need us most ... the rod bending alarmingly ... while landing a whopper ... an oak tree growing roots against the prevailing wind ... taking the punches, reeling but not out for the count... demonstrating, time after time, personal integrity ... willingness to seize opportunities, taking chances ... coping with social distancing, masks and all that... accumulating reserves for the bad times ahead ... the bloody-minded determination to press on ... disregarding trivia, focusing on what matters... a society for whom this piece resonates... deep resolve founded on inner strength... knowing it'll work out alright in the end... a word, a rich concept, a way of life... knowing when and how to concede ... more than 'putting on a brave face' ... a prerequisite for ultimate success ... facing up to adversity: bring it on... self-belief and trust in the team |
|||
|
2022-07-24 16:21:47 | Risk management trumps checklist security (lien direct) | While arguably better than nothing at all, an unstructured approach to the management of information security results in organisaitons adopting a jumble, a mixed bag of controls with no clear focus or priorities and – often – glaring holes in the arrangements. The lack of structure indicates the absense of genuine management understanding, commitment and support that is necessary to give information risk and security due attention - and sufficient resourcing - throughout the business. It's hard to imagine anyone considering such a crude, messy approach adequate, even those who coyly admit to using it! I'm not even sure it qualifies as 'an approach'. Anyway, the next rung up the ladder sees the adoption of a checklist approach: essentially, someone says 'Just adopt these N controls and you'll be secure'! It may be true that some information security controls are more-or-less universal, so any organisation that does not have them all might be missing out. Maybe it is a step up from the previous approach, and yet there are significant issues with checklists that tend to be:Basic, severely over-simplifying a complex and dynamic problem, ignoring numerous aspects while focusing attention on the N (meaning a handful);Generic but not necessarily as universal as implied, given the wide diversity of organisations out there in terms of size, maturity, industry, culture, history, business objectives, resources and so on;The 'lowest common denominator', setting a (very) low bar;Sequenced linearly in a way that implies priorities for implementation and generally disregards dependencies and linkages between items on the list, yet another over-simplification; Just someone's arbitrary selection, generally without any sound basis for selecting the listed controls and not others, other than the origantor's alleged expertise;Tricky to interpret and apply in a given situation, given the immaturity of the organisations attracted to checklist approaches; Not sufficient in most cases, and often biased towards particular types of control e.g. 'cyber' or 'compliance';Unrealistic in the presumption that simply because someone recommends the N controls, managers will therefore naively accept that they are both required and valuable;Belittleling, clearly implying that they are deliberately dumbed-down because the intended audience is, well, dumb.If N controls are inadequate or even barely sufficient, it is tempting | |||
|
2022-07-22 17:10:27 | Security in software development (lien direct) |  Prompted by some valuable customer feedback earlier this week, I've been thinking about how best to update the SecAware policy template on software/systems development. The customer is apparently seeking guidance on integrating infosec into the development process, which begs the question "Which development process?". These days, we're spoilt for choice with quite a variety of methods and approaches. Reducing the problem to its fundamentals, there is a desire to end up with software/systems that are 'adequately secure', meaning no unacceptable information risks remain. That implies having systematically identified and evaluated the information risks at some earlier point, and treated them appropriately - but how?The traditional waterfall development method works sequentially from business analysis and requirements definition, through design and development, to testing and release - often many months later. Systems security ought to be an integral part of the requirements up-front, and I appreciate from experience just how hard it is to retro-fit security into a waterfall project that has been runnning for more than a few days or weeks without security involvement.A significant issue with waterfall is that things can change substantially in the course of development: the organisation hopefully ends up with the system it originally planned, but that may no longer be the system it needs. If the planned security controls turn out to be inadequate in practice, too bad: the next release or version may be months or years away, if ever (assuming the same waterfall approach is used for maintenance, which is not necessarily so*). The quality of the security specification and design (which drives the security design, development and testing) depends on the identification and evaluation of information risks in advance, predicting threats, vulnerabilities and impacts likely to be of concern at the point of delivery some time hence.In contrast, lean, agile or rapid application development methods cycle through smaller iterations more quickly, presenting more opportunities to update security ... but also more chances to break security due to the hectic pace of change. A key problem is to keep everyone focused on security throughout the process, ensuring that whatever else is going on, sufficient attention is paid to the security aspects. Rapid decision-making is part of the challenge here. It's not just the method that needs to be agile!DevOps and scrum approaches use feedback from users on each mini-release to inform the ongoing development. Hopefully security is part of that feedback loop so that it improves incrementally at the same time, but 'hopefully' is a massive clue: if users and managers are not sufficiently security-aware to push for improvements or resist degradat |
Guideline | ||
|
2022-07-21 19:13:52 | ISO management systems assurance (lien direct) |  In the context of the ISO management systems standards, the internal audit process and accredited certification systems as a whole, are assurance controls primarily intended to confirm that organisations' management systems conform to the explicit requirements formally expressed in the respective ISO standards.A conformant management system, in turn, is expected to manage (design, direct, control, monitor, maintain …) something: for ISO/IEC 27001, that 'something-being-managed' is the suite of information security controls and other means of addressing the organisation's information risks (called 'information security risks' or 'cybersecurity risks' in the standards). For ISO 9001, it is the quality assurance activities designed to ensure that the organisation's products (goods and services) are fit for purpose. For ISO 14001, it is the controls and activities necessary to minimise environmental damage.My point is that the somethings-being-managed are conceptually distinct from the 'management systems' through which managers exert their direction and control. This is a fundamental part of the ISO management systems approach, allowing ISO to specify systems required to manage a wide variety of somethings in a similar way - a governance approach in fact.Management system certification auditors, whose sole purpose is to audit clients' management systems' conformity with the requirements expressed in the standards, have only a passing interest in those somethings-being-managed, essentially checking that they are indeed being actively managed through the management system, thereby proving that the management system is in fact operational and not just a nice neat set of policies and procedures on paper.Management system internal auditors, in contrast, may be given a wider brief by management which may include probing further into the somethings being managed ... but that's down to management's decision about the scope and purpose of the internal audits, not a formal requirement of the standards. Management may just as easily decide to have the internal auditors stick to the management system standard conformity aspects, just the same as the certification auditors. |
|||
|
2022-07-18 16:45:38 | Skyscraper of cards (lien direct) |  Having put it off for far too long, I'm belatedly trying to catch up with some standards work in the area of Root of Trust, which for me meant starting with the basics, studying simple introductory articles about RoT.As far as I can tell so far, RoT is a concept - the logical basis, the foundation on which secure IT systems are built.'Secure IT systems' covers a huge range. At the high end are those used for national security and defence purposes, plus safety- and business-critical systems facing enormous risks (substantial threats and impacts). At the low end are systems where the threats are mostly accidental and the impacts negligible - perhaps mildly annoying. Not being able to tell precisely how many steps you've taken today, or being unable to read this blog, is hardly going to stop the Earth spinning on its axis. In fact' mildly' may be overstating it.'Systems' may be servers, desktops, portables and wearables, plus IoT things and all manner of embedded devices - such as the computers in any modern car or plane controlling the engine, fuel, comms, passenger entertainment, navigation and more, or the smart controller for a pacemaker Trust me, you don't want your emotionally disturbed ex-partner gaining anonymous remote control of your brakes, altimeter or pacemaker.In terms of the layers, we the people using IT are tottering precariously on the top of a house of cards. We interact with application software, interacting with the operating system and, via drivers and microcode, the underlying hardware. A 'secure system' is a load of software running on a bunch of hardware, where the software has been designed to distrust the users and administrators, other software and the hardware, all the way down to, typically, a Hardware Security Module, Trusted Platform Module or similar dedicated security device, subsystem or chip. Ironically in relation to RoT, distrust is the default, particularly for the lower layers unless/until they have been authenticated - but there's the rub: towards the bottom of the stack, how can low-level software be sure it is interacting with and authenticating the anticipated security hardware if all it can do is send and receive signals or messages? Likewise, how can the module be sure it is interacting with the appropriate low-level software? What prevents a naughty bit of software acting as a middleman between the two, faking the expected commands and manipulating the responses in order to subvert the authentication controls? What prevents a nerdy hacker connecting logic and scope probes to the module's ports in order to monitor and maybe inject signals - or just noise to see how well the system copes? How about a we |
|||
|
2022-07-10 13:41:08 | Complexity, simplified (lien direct) | Following its exit from the EU, the UK is having to pick up on various important matters that were previously covered by EU laws and regulations. One such issue is to be addressed through a new law on online safety."Online safety: what's that?" I hear you ask. "Thank you for asking, lady in the blue top over there! Kindly allow me to elaborate ... errrr ..."'Online safety' sounds vaguely on-topic for us and our clients, so having tripped over a mention of this, I went Googling for more information. First stop: the latest amended version of the Online Safety Bill. It is written in extreme legalese, peppered with strange terms defined in excruciating detail, and littered with internal and external cross-references, hardly any of which are hyperlinked e.g. | Guideline | APT 10 | |
|
2022-07-05 11:41:40 | The discomfort zone (lien direct) |  Compliance is a concern that pops up repeatedly on the ISO27k Forum, just this morning for instance. Intrigued by ISO 27001 Annex A control A.18.1.1 "Identification of applicable legislation and contractual requirements", members generally ask what laws are relevant to the ISMS. That's a tough one to answer for two reasons. Firstly, I'm not a lawyer so I am unqualified and unable to offer legal advice. To be honest, I'm barely familiar with the laws and regs in the UK/EU and NZ, having lived and worked here for long enough to absorb a little knowledge. The best I can offer is layman's perspective. I feel more confident about the underlying generic principles of risk, compliance, conformity, obligations, accountabilities, assurance and controls though, and have the breadth of work and life experience to appreciate the next point ...Secondly, there is a huge range of laws and regs that have some relevance to information risk, security, management and the ISMS. The mind map is a brief glimpse of the landscape, as I see it ...That's a heady mix of laws and regs that apply to the organisation, its officers and workers, its property and finances, its technologies, its contracts, agreements and relationships with employees and third parties including the authorities, owners, suppliers, partners, prospects and customers, and society at large. There are obligations relating to how it is structured, operated, governed, managed and controlled, plus all manner of internal rules voluntarily adopted by management for business reasons (some of which concern obligations under applicable laws and regs). Noncompliance and nonconformity open the can-o-worms still wider with obligations and expectations about 'awareness', 'due process', 'proof' and more, much more.That A.18.1.1 control is - how shall I put it - idealistic:"All relevant legislative statutory, regulatory, contractual requirements and the organization's approach to meet these requirements shall be explicitly identified, documented and kept up to date for each information system and the organization."All requirements?! Oh boy! Explicit! Documented! Maintained! This is bewildering, scary stuff, especially for relatively inexperienced infosec or cybersecurity professionals who seldom set foot outside of the IT domain. We're definitely in the |
Guideline | ||
|
2022-07-02 12:23:41 | Standards development - a tough, risky business (lien direct) |  News emerged during June of likely further delays to the publication of the third edition of ISO/IEC 27001, this time due to the need to re-align the main body clauses with ISO's revised management systems template. The planned release in October is in some doubt. Although we already have considerable discretion over which information security controls are being managed within our ISO/IEC 27001 Information Security Management Systems today, an unfortunate side-effect of standardisation, harmonisation, adoption, accreditation and certification is substantial inertia in the system as a whole. It's a significant issue for our field where the threats, vulnerabilities, impacts and controls are constantly shifting and often moving rapidly ahead of us … but to be honest it's equally problematic for other emerging and fast-moving fields. Infosec is hardly special in this regard. Just look at what's happening in microelectronics, IT, telecomms, robotics, environmental protection and globalisation generally for examples. One possible route out of the tar-pit we've unfortunately slid into is to develop forward-thinking 'future-proof' standards and release them sooner, before things mature, but that's a risky approach given uncertainties ahead. It would not be good for ill-conceived/premature standards to drive markets and users in inappropriate directions. It's also tough for such a large, ponderous, conservative committee as ISO/IEC JTC 1/SC 27. However, the smart city privacy standard ISO/IEC TS 27570 is a shining beacon of light, with promising signs for the developing security standards on Artificial Intelligence and big data security too. I wish I could say the same of 'cyber', cloud and IoT security but (IMNSHO) the committee is struggling to keep pace with these fields, despite some fabulous inputs and proactive support from members plus the likes of the Cloud Security Alliance and NIST. The floggings will continue until morale improves.Another tar-pit escape plan involves speeding-up the standards development process, perhaps also the promotion, accreditation and certification processes that follow each standard's publication – but again there are risks in moving ahead too fast, compromising the quality and value of the standards, damaging ISO/IEC's established brands. |
Guideline | ||
|
2022-07-01 13:00:00 | Shout, shout, let it all out (lien direct) |  Here's an insightful and enjoyable way to explore your psyche and vent a little tension at the end of a tough month.First, find yourself a private space to watch Tears for Fears.Now shout, shout, let it all out: what are the things you could do without? Come on, I'm talking to you, come on.Grab a scrap of paper and start writing down the things you could do without. You'll find yourself stimulated by your own words to think of other things, other stuff you don't want, don't like, can't stand, even hate. Fine, scribble away.How's it going? How do you feel now - vented? Released? If it all gets too much, take a break. Set your list aside to ferment for a while - as long as it takes. There's no rush. You're the boss. If you are so inclined, come back later to tidy up your list and make sense of it. How you do that is up to you. For me, it's mind-mapping, grouping things together, drawing links and doodling. I'll show you mine - well an uncontroversial snippet anyway ... When you're ready, fully vented, destroy that bit of paper. Let it go, or maybe rip it up and start again. |
|||
|
2022-06-30 16:35:04 | What are "information assets"? (lien direct) |  Control 5.9 in ISO/IEC 27002:2022 recommends an inventory of information assets that should be “accurate, up to date, consistent and aligned with other inventories”. Fair enough, but what are 'information assets'? What, exactly, are we supposed to be inventorying? The standard refers repeatedly but enigmatically to "information and other associated assets" that an organisation's Information Security Management System protects. The intended meaning of 'information asset' has been a bone of contention within ISO/IEC JTC 1/SC 27 for years, some experts and national bodies vehemently disagreeing with each other until, eventually, a fragile ceasefire was declared in order to move forward on the numerous standards projects that hinge on the term. Currently, '27002 provides a rather broad and unhelpful definition of "asset" as "anything that has value to the organisation" - paperclips, for instance, fall within the definition. Does that mean your ISMS should protect paperclips since, arguably, they are 'associated with information', albeit very low value assets. I know this is reductio ad absurdam but it illustrates the tar pit that SC 27 found itself in.On a more pragmatic note, I have consciously taken a wide view of information assets in preparing a checklist of information assets for SecAware. I intend to set you thinking about the potential scope, purpose and focal points of your ISMS. You may feel that certain items on the checklist are irrelevant ... or the checklist might just open your eyes to entire categories of valuable information that you hadn't even considered. Whether they end up in or out of scope of your ISMS is for you and your management colleagues to determine. I'm simply giving you food for thought.  |
|||
|
2022-06-30 13:02:25 | Authorised exemptions (lien direct) | Inspired by an exchange on the ISO27k Forum yesterday morning, I wrote and published a simple 2-page exemptions policy template for SecAware.  In essence, after explaining what 'exemptions' are, the policy requires that they are authorised after due consideration by management, specifically the relevant Information Owners. Exemption decisions should also be recorded, hinting at a process and some sort of exemptions log. I'm wondering now whether to write a procedure as well, including a basic log template as a starting point. I'm also contemplating writing something on accountability and responsibility, and perhaps generic incident management and post incident review procedures to accompany the incident management policy. |
|||
|
2022-06-28 08:29:13 | The business context for information risk and security (lien direct) | Although the organisational/business context is clearly relevant and important to information risk and security management, it is tricky to describe. In my opinion, clause 4 of ISO/IEC 27001 is so succinct that it leaves readers perplexed as to what 'context' even means. It stops short of explaining how to determine and make use of various 'internal and external issues' in an Information Security Management System. So, to help clients, I wrote and released a pragmatic 5-page management guideline on this for the SecAware ISMS toolkit, expanding on this neat little summary diagram:  With about a thousand words of explanation and pragmatic advice, the guideline has roughly ten times as many words as clauses 4.1 and 4.2 ... or twenty times if you accept that the picture is worth a thousand words. It was written independently of, and complements, ISO/IEC 27003's advice in this area.Although I am happy with the SecAware ISMS toolkit materials as they are, I'm always looking for improvement opportunities, ways to add more value for clients. I'm currently working on, or at least thinking about:A set of fundamental information risk and security principles;A guideline on the Risk Treatment Plan and Statement of Applicability;Something on security engineering. |
|||
|
2022-06-24 13:40:08 | The sadly neglected Risk Treatment Plan (lien direct) |  For some curious reason, the Statement of Applicability steals the limelight in the ISO27k world, despite being little more than a formality. Having recently blogged about the dreaded SoA, 'nuff said on that.Today I'm picking up on the SoA's shy little brother, the Risk Treatment Plan. There's a lot to say and think about here, so coffee-up, settle-down, sit forward and zone-in.ISO/IEC 27001 barely even acknowledges the RTP. Here are the first two mentions, tucked discreetly under clause 6.1.3: |
Threat Guideline | APT 19 APT 10 | ★★★★ |
|
2022-06-22 09:36:12 | Infosec principles (Hinson tips) (lien direct) |  Thinking about the principles underpinning information risk and security, here's a tidy little stack of "Hinson tips" - one-liners to set the old brain cells working this chilly mid-Winter morning:Address information confidentiality, integrity and availability, broadlyAddress internal and external threats, both deliberate and accidental/naturalCelebrate security wins: they are rare and valuableComplete security is unattainable, an oxymoronComplexity is the arch-enemy of security: the devil's in the details Consider all stakeholders - users, administrators, maintainers and attackers Consider threats, vulnerabilities and impacts Controls modify or maintain riskDefence-in-depth layers complementary controls of different typesDon't trust anything untrustworthy Ensure business continuity through resilience, recovery and contingencyEven barely sufficient security is a business-enablerExcessive security is a business-impediment, more likely to be bypassedExploiting information can be a good or a bad thing, depending on contextFailure is a possibility, so fail-safe means fail-secure Focus on significant risks and the associated key controlsGeneral-purpose controls such as oversight and awareness bolster the restGiven practical limits to attainable security, residual risks are inevitableGood security isn't costly: it's valuable, good for business Identify, evaluate and treat risks systematicallyInformation content is a valuable yet vulnerable assetLack of control is neither threat nor vulnerabilityOffensive security is a viable approach, within reasonPeople can be our greatest threats and our most valuable alliesReducing exposure reduces riskResidual (e.g. accepted, shared or unidentified) risks ar |
Threat | ||
|
2022-06-21 11:28:45 | WANTED: a set of infosec principles we can all agree on (lien direct) | The SecAware corporate information security policy template incorporates a set of generic principles for information risk and security such as "Our Information Security Management System conforms to generally accepted good security practices as described in the ISO/IEC 27000-series information security standards." and "Information is a valuable business asset that must be protected against inappropriate activities or harm, yet exploited appropriately for the benefit of the organization." Despite being reasonably happy with the 7 principles I selected, I would prefer to base the policy on a generally-accepted set of infosec principles, akin to the OECD Privacy Principles first published with remarkable foresight way back in 1980. There are in fact several different sets of principles Out There, often incomplete and imprecisely stated. Different authors take different perspectives, emphasizing different aspects, and the contexts and purposes also differ. It will be an 'interesting' challenge for ISO/IEC JTC 1/SC 27 to tease out, elaborate on, fine-tune and hopefully reach consensus on a reasonably succinct, coherent, comprehensive set of generally-applicable 'concepts and principles' for the next edition of ISO/IEC 27000. I just hope the learned committee doesn't end up specifying a racehorse looking something like this ... | |||
|
2022-06-19 09:54:39 | The Matrix, policy edition (lien direct) | Inspired by an insightful comment on LinkeDin from an SC 27 colleague on the other side of the world (thanks Lars!), I spent most of last week updating the SecAware security policy templates and ISO27k ISMS materials.The main change was to distinguish conformity from compliance - two similar terms that I admit I had been using loosely and often incorrectly for far too long. As I now understand them:Compliance refers to fulfilling binding (mandatory) legal, regulatory and contractual obligations; Conformity concerns fulfilling optional (discretionary) requirements in standards, agreements, codes of ethics etc. It's a fine distinction with implications for the associated information risks, given differing impacts: Noncompliance may lead to legal enforcement action (fines/penalties), other costly sanctions (such as more intrusive monitoring by the authorities and perhaps revocation of operating licenses) and business issues (such as reputational damage and brand devaluation, plus the costs of defending legal action). The consequences of nonconformity may be trivial or nothing at all if nobody even cares, but can also involve business issues such as inefficiencies, excess costs and so on, particularly if customers, business partners, the authorities or other stakeholders are seriously concerned at management's apparent disregard for good security practices.Certification of an organisation's ISMS, then, demonstrates its conformity with, not compliance to, ISO/IEC 27001 - well in most cases anyway, where management voluntarily chooses to adopt and conform to the standard. If they are obliged by some mandatory, legally-binding requirement (an applicable law or regulation, or perhaps terms in a formal contract with a supplier or customer, or perhaps a law or regulation), I guess they must comply. Putting that another way, nonconformity is an option. Noncompliance isn't.Anyway, having adjusted the terminology and tweaked the SecAware materials, I took the opportunity to prepare two new 'bulk deal' packages - a comprehensive suite of information security policy templates, and a full set of ISO27k ISMS materials. I'm hoping to persuade customers to spend invest a little more for greater returns. The SecAware policies, for instance, are explicitly designed to work best as a whole, an integrated and coherent suite as opposed to an eclectic collection of policies on various discrete topics. In recent years, I have developed a spreadsheet to track the mesh of relationships between policies: | Guideline | ||
|
2022-06-14 11:09:22 | ISO/IEC 27400 IoT security and privacy standard published (lien direct) |  To celebrate the publication of ISO/IEC 27400:2022 today, we have slashed the price for our IoT security policy templates to just $10 each through SecAware.com.IoT policy is the first of the basic security controls shown on the 'risk-control spectrum' diagram above, and is Control-01 in the new standard ... Do you have a security policy on IoT? If not, does that mean IoT is out of control in your organisation? Even if you do, what does it say? Is it valid, appropriate, worthwhile, sufficient? The spectrum diagram shows quite a variety of risks and controls, but it is merely a summary, selected highlights. Attempting to cover them all in a policy document would be counterproductive - in fact, general employees can barely cope with a much-simplified one-page 'acceptable use policy'. The new ISO/IEC 27400 standard takes a broad perspective with copious advice on information security and privacy for the designers, manufacturers, purchasers, users and administrators of IoT things. |
|||
|
2022-06-08 16:28:55 | Third edition of ISO/IEC 27001 coming (lien direct) |  An ISO/IEC JTC 1/SC 27 meeting last night was informed that the planned amendment to ISO/IEC 27001:2013 is to be absorbed into a new third edition of the standard to become ISO/IEC 27001:2022.Apparently, the new 2022 version of '27001 will have minor editorial corrections in the main body text (including one of the two corrigenda published previously), a small but valuable clarification to the notes on subclause 6.1.3, and a complete replacement for Annex A reflecting ISO/IEC 27002:2022.The transition arrangements are still uncertain but this is my understanding:Nobody will be able to use ISO/IEC 27001:2022 formally until it is published, hopefully on October 1st;The International Accreditation Forum will publish a mandate for the national accreditation bodies (such as IANZ here in New Zealand) at the same time, with details of the 3 year transition period:Accreditation and certification bodies will be required to update their processes, and train and prepare auditors for accreditation and certification against the new standard within a year of its release;Organisations may wish to be certified against the new standard as soon as the certification bodies are ready to do so, or may (continue to) use the old standard for up to three years beyond its release, meaning a full certification cycle;Already (right now), organisations are free to declare any or all of the controls in ISO/IEC 27001:2013 Annex A inapplicable in their Statement of Applicability, instead opting to use an appropriate selection of controls e.g. from ISO/IEC 27002:2022, NIST SP800-50, NIST CSF, ISF, COBIT, CSA, GDPR, PCI-DSS and whatever other sources they like (including entirely custom control sets) in accordance with the current ISO/IEC 27001:2013 clause 6.1.3 note 2, which says in part "The control objectives andcontrols listed in Annex A are not exhaustive and additional control objectives and controls may be needed." Regardless of where the controls come from, organisations must: |
|||
|
2022-06-06 10:06:44 | The dreaded Statement of Applicability (lien direct) |  Subclause 6.1.3 of ISO/IEC 27001:2013 requires compliant organisations to define and apply an information security risk treatment process to:a) select appropriate information security risk treatment options, taking account of the risk assessment results;The 'risk treatment options' (including the information security controls) must be 'appropriate' and must 'take account of ' (clearly relate to) the 'risk assessment results'. The organisation cannot adopt a generic suite of information security controls simply on the basis that they have been recommended or suggested by someone - not even if they are noted in Annex A.b) determine all controls that are necessary to implement the information security risk treatment option(s) chosen;NOTE Organizations can design controls as required, or identify them from any source.This requirement clearly specifies the need to determine all the controls that the organisation deems necessary to mitigate unacceptable information risks. Note, however, that it doesn't actually demand they are fully implemented: see point d) below.c) compare the controls determined in 6.1.3 b) above with those in Annex A and verify that no necessary controls have been omitted; NOTE 1 Annex A contains a comprehensive list of control objectives and controls. Users of this International Standard are directed to Annex A to ensure that no necessary controls are overlooked. NOTE 2 Control objectives are implicitly included in the controls chosen. The control objectives and controls listed in Annex A are not exhaustive and additional control objectives and cont |
Guideline | ||
|
2022-05-29 09:50:29 | Algo-rhythmic infosec (lien direct) |  An article by the 50-year-old University of York Department of Computer Science outlines algorithmic approaches in Artificial Intelligence. Here are the highlights:Linear sequence: progresses directly through a series of tasks/statements, one after the other.Conditional: decides between courses of action according to the conditions set (e.g. if X is 10 then do Y, otherwise do Z).Loop: sequential statements are repeated. Sequential statements are repeated.Brute force: tries approaches systematically, blocking off dead ends to leave only viable routes to get closer to a solution.Recursive: apply the learning from a series of small episodes to larger problems of the same type.Backtracking: incrementally builds a data set of all possible solutions, retracing or undoing/reversing its last step if unsuccessful in order to pursue other pathways until a satisfactory result is reached. Greedy: quickly goes to the most obvious solution (low-hanging fruit) and stops. Dynamic programming: outcomes of prior runs (solved sub-problems) inform new approaches. Divide and conquer: divides the problem into smaller parts, then consolidates the solutions into an overall result.Supervised learning: programmers train the system using structured data, indicating the correct answers. The system learns to recognise patterns and hence deduce the correct results itself when fed new data.Unsupervised learning: the system is fed unlabeled ('raw') input data that it autonomously mines for rules, detecting patterns, summarising and grouping data points to describe the data set and offer meaningful insights to users, even if the humans don't know what they're looking for.Reinforcement learning: the system learns from its interactions with the environment, utilising these observations to take actions that either maximise the reward or minimise the risk.Aside from computerised AI, we humans use similar approaches naturally, for instance when developing and implementing information security policies:Linear sequence: start with some sort of list of desireable policies, sorted in some manner, working down from top to the bottom. |
|||
|
2022-05-26 14:13:08 | Iterative scientific infosec (lien direct) |  Here's a simple, generic way to manage virtually anything, particularly complex and dynamic things: Think of something to do Try itWatch what happensDiscover and learnIdentify potential improvementsGOTO 1It's a naive programmer's version of Deming's plan-do-check-act cycle - an iterative approach to continuous improvement that has proven very successful in various fields over several decades. Notice that it is rational, systematic and repeatable.Here's a similar grossly-simplified outline of the classical experimental method that has proven equally successful over several centuries of scientific endeavour:Consider available informationPropose a testable hypothesisTest it (design and run experiments)Watch what happensDiscover and learnGOTO 1Either way, I'm a committed fan. The iterative approach with incremental improvements, works well. I approve.Along the way, aside from pushing back the frontiers of science and technology and achieving remarkable advances for human society, we've also learned about the drawbacks and flaws in the processes, and we've developed assorted mechanisms to reduce the risks and increase our chances of success e.g.: Key to 'improving' or 'advancing' is to be able to recognise and ideally measure the improvement or advance - in most cases anyway. Improvements or advances that happen purely by chance ('discoveries') are welcome but rare treats. A big issue in quality assurance is the recognition that there are usually several competing and sometimes contradictory requirements/expectations, not least the definition of 'quality'. For certain customers, a rusty old heap of a car discovered in a barn is just as much the 'quality vehicle' as a Rolls Royce to its customers. Likewise, security improvements depend on one's persp |
Patching | ||
|
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-05-18 15:41:53 | Hacking the Microsoft Sculpt keyboard (lien direct) |  In its infinite wisdom, Microsoft designed data encryption into the Sculpt wireless keyboard set to protect against wireless eavesdropping and other attacks. The keyboard allegedly* uses AES for symmetric encryption with a secret key burnt into the chips in the keyboard's very low power radio transmitter and the matching USB dongle receiver during manufacture: they are permanently paired together. The matching Sculpt mouse and Sculpt numeric keypad use the same dongle and both are presumably keyed and paired in the same way as the keyboard.This design is more secure but less convenient than, say, Bluetooth pairing. The risk of hackers intercepting and successfully decoding my keypresses wirelessly is effectively zero. Nice! Unfortunately, the keyboard, keypad and mouse are all utterly dependent on the corresponding USB dongle, creating an availability issue. Being RF-based, RF jamming would be another availability threat. Furthermore, I'm still vulnerable to upstream and downstream hacking - upstream meaning someone coercing or fooling me into particular activities such as typing-in specific character sequences (perhaps cribs for cryptanalysis), and downstream including phishers, keyloggers and other malware with access to the decrypted key codes etc.So yesterday, after many, many happy hours of use, my Sculpt's unreliable Ctrl key and worn-out wrist rest finally got to me. I found another good-as-new Sculpt keyboard in the junkpile, but it was missing its critical USB dongle. The solution was to open up both keyboards and swap the coded transmitter from the old to the new keyboard - a simple 20 minute hardware hack.In case I ever need to do it again, or for anyone else in the same situation, here are the detailed instructions:Assemble the tools required: a small cross-head screwdriver; a stainless steel dental pick or small flat-head screwdriver; a plastic spudger or larger flat-head screwdriver (optional); a strong magnet (optional). Start with the old keyboard. Peel off the 5 rubber feet under the keyboard, revealing 5 small screws. Set the feet aside to reapply later.Remove all 5 screws. Note: the 3 screws under the wrist rest are slightly longer than the others, so keep them separate.Carefully ease the wrist rest away from the base. It is a 'snap-fit' piece. I found I could lever it off using my thumbs at the left or right sides, then gradually work around the edge releasing it. You may prefer to use the spudger. It will flex a fair bit but it is surprisingly strong.Under the wrist rest are anot |
Malware Tool | ||
|
2022-05-15 17:18:34 | What actually drives information security? (lien direct) |  The 'obvious' driver for information security is information risk: valuable yet vulnerable information must be secured/protected against anything that might compromise its confidentiality, integrity or availability, right? Given an infinite array of possible risks and finite resources to address them, information risk analysis and management techniques help us scan the risk landscape for things that stand out - the peaks - and so we play whack-a-mole, attempting to level the field through mitigating controls, remainingly constantly on the lookout for erupting peaks and those hidden behind the ones we can see or were otherwise transparent.That's 'obvious' from my perspective as an experienced information risk and security professional, anyway. Your perspective probably differs. You may look at things from a slightly or dramatically different angle - and that's fine. I see these as interesting and stimulating complementary approaches, not alternatives.Compliance, for instance, is a strong driver in some cultures and organisations. Quality, efficiency and effectiveness drive others. Some seek to apply good practices, joining the pack. Customer-centric businesses naturally focus on customer satisfaction, brand values, loyalty etc. Startups are concerned to grow rapidly, hence anything that is or might become a barrier is a target. Government organisations, charities, professional services organisations, utilities, schools, assorted industries etc. all have their own focal points and concerns. Profits are clearly important for commercial organisations, but there are other financial measures too - and indeed many other things to measure. Information risk and security is incidental or supportive for most of them, enabling for some and essential for a select few whose business is information security, or the enlightened (as I like to call them).So, in your own situation, consider the business perspective. What does management want/expect out of information security? Along with what they do not want or expect to avoid, these are worthwhile aspects to explore. |
|||
|
2022-05-14 17:22:46 | Managing professional services engagements (lien direct) |  In relation to professional services, management responsibilities are shared between client and provider, except where their interests and concerns diverge. Identifying and exploiting common interests goes beyond the commercial/financial arrangements, involving different levels and types of management:Strategic management: whereas some professional services may be seen as short-term point solutions to specific issues ("temping"), many have longer-term implications such as the prospect of repeat/future business if things work out so well that the engagement is clearly productive and beneficial to both parties. Establishing semi-permanent insourcing and outsourcing arrangements can involve substantial investments and risks with strategic implications, hence senior management should be involved in considering and deciding between various options, designing and instituting the appropriate governance and management arrangements, clarifying responsibilities and accountabilities etc. Organisations usually have several professional services suppliers and/or clients. Aside from managing individual relationships, the portfolio as a whole can be managed, perhaps exploiting synergistic business opportunities (e.g. existing suppliers offering additional professional services, or serving other parts of the client organisation or its business partners). Tactical and operational management: planning, conducting, monitoring and overseeing assignments within a professional services engagement obviously involves collaboration between client and provider, but may also affect and be affected by the remainder of their business activities. A simple example is the provision and direction of the people assigned to assignments, perhaps determining their priorities relative to other work obligations. If either party's management or workforce becomes overloaded or is distracted by other business, the other may need to help out and perhaps take the lead in order to meet agreed objectives - classic teamwork.Commercial management: negotiating and entering into binding contracts or agreements can be a risky process. Getting the best value out of the arrangements includes not just the mechanics of invoicing and settling the bills accurately and on time, but getting the most out of all the associated resources, including the information content. Relationship management: anyone over the age of ten will surely appreciate that relationships are tough! There are just so many dimensions to this, so much complexity and dynamics. In respect of professional services, there are both organisational and personal relationships to manage, while 'manage' is more about guiding, monitoring and reacting than directing and controlling. Despite the formalities of laws, contracts and policies, relationships seemingly play by their o |
Guideline | ||
|
2022-05-11 18:51:20 | AA privacy breach --> policy update? (lien direct) |  According to a Radio New Zealand news report today:"Hackers have taken names, addresses, contact details and expired credit card numbers from the AA Traveller website used between 2003 and 2018. AA travel and tourism general manager Greg Leighton said the data was taken in August last year and AA Traveller found out in March. He said a lot of the data was not needed anymore, so it should have been deleted, and the breach "could have been prevented"."The disclosure prompted the acting NZ Privacy Commissioner to opine that companies 'need a review policy':"Acting Privacy Commisioner Liz Macpherson told Midday Report that if data was not needed it should be deleted ... Companies needed a review policy in place to determine if the data stored was neccessary, or could be deleted, Macpherson said."So I've looked through our SecAware information security policies to see whether we have it covered already, and sure enough we do - well, sort-of. Our privacy compliance policy template says, in part:"IT systems, cloud services and business processes must comply fully with applicable privacy laws throughout the entire development lifecycle from initial specification though testing, release, operation, management and change, to final retirement. For example, genuine (as opposed to synthetic) personal information used during the development process (e.g. for testing) must be secured just as strongly as in production, and securely erased when no longer required."The final clause in that paragraph refers to 'secure erasure' without specifying what that really means, and 'when no longer required' is just as vague as determining whether the data remains 'necessary'. That said, the remainder of the paragraph, and in fact the rest of the policy template, covers other relevant and equally important issues - including compliance with applicable p |
★★★ | ||
|
2022-05-11 10:30:05 | How many metrics? (lien direct) | While perusing yet another promotional, commercially-sponsored survey today, something caught my beady eye. According to the report, "On average, organizations track four to five metrics". Four to five [cybersecurity] metrics?!! Really? Oh boy.Given the importance, complexities and breadth of cybersecurity, how on Earth can anyone sensibly manage it with just four to five metrics? It beggars belief, particularly as the report indicates that three quarters of the 1,200 surveyed companies had at least a $billion in revenue, and more than half of them have at least 10,000 employees. With a total cybersecurity expenditure of $125billion (around 80% of the total global estimate), these were large corporations, not tiddlers.The report indicates the corresponding survey question was "Q30. Which of the following cybersecurity metrics does your organization track, and which metrics are the most important?". Well OK, that's two questions in one, and 'the following cybersecurity metrics' are not stated.Having been quietly contemplating that one remarkable, counter-intuitive finding for about an hour, I've thought up a bunch of potential explanations so far:The four to five cybersecurity metrics are just those considered 'key' by the CISOs and other senior people surveyed.The four to five are just the respondents' choices from the 16 metrics presumably offered in the question (we aren't told what metrics were offered in the question, but there are 16 listed in the report).Cybersecurity is not being managed sensibly.Cybersecurity is not being managed.Cybersecurity is not what I think it is - a neologism for IT security or more specifically Internet security protecting against deliberate, malicious attacks by third parties. CISOs and the like haven't got a clue what they are doing.Most CISOs and the like chose not to answer the question (of the 1,200 companies surveyed, we aren't told how many respondents answered this or indeed any other question: perhaps they were getting bored by question 30 of an unknown total).CISOs and the like simply lied, for some reason, or their responses were inaccurately/ineptly recorded.The word 'track' in the question strongly implies that the four to five metrics are measured and reported regularly, showing trends over time. Other metrics that are not 'tracked' in this way were not noted.The survey was ineptly designed, conducted, analysed and/or reported.The survey was non-scientific, biased towards the interests of the commercial sponsors (who, presumably, offer 'solutions' measured by the chosen metrics ...).The survey company is | Guideline | ★★★ | |
|
2022-05-11 09:25:05 | (Déjà vu) Threat intelligence policy (lien direct) |  I finally found the time today to complete and publish an information security policy template on threat intelligence. The policy supports the new control in ISO/IEC 27002:2022 clause 5.7: "Information relating to information security threats should be collected and analysed to produce threat intelligence."The SecAware policy template goes a little further: rather than merely collecting and analysing threat intelligence, the organisation should ideally respond to threats - for example, avoiding or mitigating them. That, in turn, emphasises the value of 'actionable intelligence', in the same way that 'actionable security metrics' are worth more than 'coffee table'/'nice to know' metrics that are of no practical use. The point is that information quality is more important that its volume. This is an information integrity issue, as much as information availability.The policy also mentions 'current and emerging threats'. This is a very tricky area because novel threats are generally obscure and often deliberately concealed in order to catch out the unwary. Maintaining vigilance for the early signs of new threat actors and attack methods is something that distinguishes competent, switched-on security analysts from, say, journalists.The policy template costs just $20 from www.SecAware.com. I'll be slaving away on other new policies this week, plugging a few remaining gaps in our policy suite - and I'll probably blog about that in due course. |
Threat | ||
|
2022-05-11 09:24:18 | Data masking and redaction policy (lien direct) |  Last evening I completed and published another SecAware infosec policy template addressing ISO/IEC 27002:2022 clause 8.11 "Data masking":"Data masking should be used in accordance with the organization's topic-specific policy on access control and other related topic-specific, and business requirements, taking applicable legislation into consideration."The techniques for masking or redacting highly sensitive information from electronic and physical documents may appear quite straightforward. However, experience tells us the controls are error-prone and fragile: they generally fail-insecure, meaning that sensitive information is liable to be disclosed inappropriately. That. in turn, often leads to embarrassing and costly incidents with the possibility of prosecution and penalties for the organisation at fault, along with reputational damage and brand devaluation.The policy therefore takes a risk-based approach, outlining a range of masking and redaction controls but recommending advice from competent specialists, particularly if the risks are significant.The $20 policy template is available here.Being a brand new policy, it hasn't yet had the benefit of the regular reviews and updates that our more mature policies enjoy ... so, if you spot issues or improvement opportunities, please get in touch.As usual, I have masked/redacted the remainder of the policy for this blog and on SecAware.com by making an image of just the first half page or so, about one eigth of the document by size but closer to one quarter of the policy's information value. So I'm giving you about $5's worth of information, maybe $4 since the extract is just an image rather than an editable document. On that basis, similar partial images of the 80-odd security policy templates offered through SecAware.com are worth around $320 in total. It's an investment, though, a way to demonstrate the breadth, quality, style and utility of our products and so convince potential buyers like you to invest in them. |
Guideline | ||
|
2022-05-10 16:37:36 | Threat intelligence policy (lien direct) | I finally found the time today to complete and publish an information security policy template on threat intelligence. The policy supports the new control in ISO/IEC 27002:2022 clause 5.7: "Information relating to information security threats should be collected and analysed to produce threat intelligence."The SecAware policy goes a little further: rather than merely collecting and analysing threat intelligence, the organisation should ideally respond to threats - for example, avoiding or mitigating them. That, in turn, emphasises the value of 'actionable intelligence', in the same way that 'actionable security metrics' are worth more than 'coffee table'/'nice to know' metrics that are of no practical use. The point is that information quality is more important that its volume. This is an information integrity issue, as much as information availability.The policy also mentions 'current and emerging threats'. This is a very tricky area because novel threats are generally obscure and often deliberately concealed in order to catch out the unwary. Maintaining vigilance for the early signs of new threat actors and attack methods is something that distinguishes competent, switched-on security analysts from, say, journalists.The policy template costs just $20 from www.SecAware.com. I'll be slaving away on other new policies this week, plugging a few remaining gaps in our policy suite - and I'll probably blog about that in due course. |
Threat | ★★★ | |
|
2022-04-24 12:23:00 | Professional services - concluding phase (lien direct) |  Having introduced this blog series and covered information risks applicable to the preliminary and operational phases of a professional services engagement, it's time to cover the third and final phase when the engagement and business relationship comes to an end.Eventually, all relationships draw to a close. Professional services clients and providers go their separate ways, hopefully parting on good terms unless there were unresolved disagreements, issues or incidents (hinting at some information risks).It is worth considering what will/might happen at the end of a professional services engagement as early as the preliminary pre-contract phase. Some of the controls need to be predetermined and pre-agreed in order to avoid or mitigate potentially serious risks later-on. Straightforward in principle ... and yet easily neglected in the heady rush of getting the engagement going. This is not unlike a couple drawing up their "pre-nup" before a wedding, or a sensible organisation making suitable business continuity arrangements in case of severe incidents or disasters ahead. A potentially significant information risk in the concluding phase stems from the inappropriate retention by either party of [access to] confidential information obtained or generated in the course of the engagement - whether commercially sensitive or personal information. Imagine the implications of, say, a law firm being hit by a ransomware attack, office burglary or insider incident, giving miscreants access to its inadequately-secured client casework files and archives. Meta-information about the engagement, assignment/s and contracts may also be commercially-sensitive, for instance if the supplier deliberately under-priced the contract to secure the business and gain a foothold in the market, only to find it uneconomic to deliver the contracted services - a decidedly embarrassing situation if disclosed.Information risks in this phase are amplified if the relationship e |
Ransomware Guideline | ||
|
2022-04-23 18:06:15 | Topic-specific policy 11/11: secure development (lien direct) | The final topic-specific policy example from ISO/IEC 27002:2022 is another potential nightmare for the naïve and inexperienced policy author. Policy scoping Despite the context and presumed intent, the title of the standard's policy example ("secure development") doesn't explicitly refer to software or IT. Lots of things get developed - new products for instance, business relationships, people, corporate structures and so on. Yes, even security policies get developed! Most if not all developments involve information (requirements/objectives, specifications, plans, status/progress reports etc.) and hence information risks ... so the policy could cover those aspects, ballooning in scope from what was presumably intended when the standard was drafted.Even if the scope of the policy is constrained to the IT context, the information security controls potentially required in, say, software development are many and varied, just as the development and associated methods are many and varied, and more poignantly so too are the information risks. Policy development Your homework challenge, today, is to consider, compare and contrast these five markedly different IT development scenarios:Commercial firmware being developed for a small smart actuator/sensor device (a thing) destined to be physically embedded in the pneumatic braking system of commercial vehicles such as trucks and coaches, by a specialist OEM supplier selected on the basis of lowest price. A long-overdue technical update and refresh for a German bank's mature financial management application, developed over a decade ago by a team of contractors long since dispersed or retired, based on an obsolete database, with fragmentary documentation in broken English and substantial compliance implications, being conducted by a large software house based entirely in India. A cloud-based TV program scheduling system for a global broadcaster, to be delivered iteratively over the next two years by a small team of contractors under the management of a consultancy firm for a client that freely admits it barely understands phase 1 and essentially has no idea what might be required next, or when.A departmental spreadsheet for time recording by home workers, so their time can be tracked and recharged to clients, and their productivity can be monitored by management.Custom hardware, firmware and autonomous software required for a scientific exploration of the Marianas trench - to be deployed in the only two deep-sea drones in existence that are physically capable of delivering and recovering the payload at the extreme depths required.You may have worked in or with projects/initiatives vaguely similar to one, maybe even two or three of these, but probably not all five - and th | Patching Guideline | ||
|
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-23 12:40:00 | Professional services - operational (lien direct) |  Following-on from the preliminary phase I covered yesterday, the longest phase of most professional services engagements is the part where the services are delivered. With the contractual formalities out of the way, the supplier starts the service, providing consultancy support or specialist advice. The client receives and utilises the service. Both 'sides' are important to both parties, since a professional service that isn't delivered and used doesn't generate value for the client, and is unlikely to lead to repeat business - such as additonal assignments: Deliberately taking a simplistic view once again, I have represented 'assignments' (which may be projects, jobs, tasks or whatever) as discrete pieces of work, each with a beginning, middle and end:  Things are never so neat and tidy in practice. Some assignments may never really get off the ground, and some gradually diminish or peter out rather than coming to an abrupt end. On-again-off-again assignments are challenging to plan and resource. Assignments may blend into each other or split apart. If the same supplier resources (mostly people) are involved in multiple assignments, possibly for multiple clients, t |
Guideline | ||
|
2022-04-23 11:09:24 | EU to standardise on ISO 31000 and ISO/IEC 27005? (lien direct) |  "Risk management procedures are fundamental processes to prepare organisations for a future cybersecurity attack, to evaluate products and services for their resistance to potential attacks before placing them on the market, and to prevent supply chain fraud" says ENISA in the report "RISK MANAGEMENT STANDARDS - Analysis of standardisation requirements in support of cybersecurity policy" published in March 2022. Not to be left behind, ENISA - originally the European Network and Information Security Agency (an official agency of the EU) - leapt aboard the cyber bandwagon, rebranding itself "The European Union Agency for Cybersecurity" when it became a permanent EU agency under the European Cybersecurity Act, regulation (EU) 2019/881. Despite the vague title, RISK MANAGEMENT STANDARDS in fact primarily concerns "risk management [and] security of ICT products, ICT services and ICT processes" where 'risk' means "any reasonably identifiable circumstance or event having a potential adverse effect on the security of network and information systems." Apparently, "The main goal of risk management is (in general) to protect ICT products (software, hardware, systems, components, services) and business assets, and minimise costs in cases of failures. Thus it represents a core duty for successful business or IT management." In other words, the ENISA document revolves around IT risks, primarily, although it does casually mention 'enterprise risk management' which takes in operational, market, supply chain, project, strategic and other risks. Unfortunately, I haven't dug deep enough yet to reveal actual defiinitions of key terms such as "cybersecurity" or "sector". Evidently, we are supposed to just know what they mean. It doesn't help that the cited "Methodology for Sectoral Cybersecurity Asssessments 2021" official download appears to be broken, but consulting another source I see that it doesn't even define those terms anyway. Furthermore, an embedded diagram suggests an unconventional interpretation of 'risk' and 'exposure', while 'threat' seemingly disregards unintentional and untargeted threats such as generic malware, accidents and storms: |
Guideline | ||
|
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 | ||
|
2022-04-21 17:39:36 | Information risk and security for professional services (lien direct) | When you acquire or provide professional services, how do you address the associated information risks? I have in mind consultancy, advisory and other specialist services such as:Building and construction services e.g. architecture, surveying;Business services e.g. marketing and sales, strategy and management consulting, auditing, quality consulting;Engineering services e.g. electrical and electronic design, materials science, measurement and calibration;Financial services e.g. book-keeping and accounting, investment, tax and insurance advice, credit-checking;Human resources services e.g. recruitment, employment disputes, mentoring and training;IT and telecommunications services e.g. Internet services, cloud computing, technical support and advice, outsourced development, datacentre facilities;Legal services e.g. commercial and family law, contracting, disputes, compliance, forensics, prosecution and defence, intellectual property protection;Security services e.g. information risk and security consulting, IT auditing, digital forensics, identity and background checking, surveillance;... and others. Professional services are information-centric: information is the work product, the purpose, the key deliverable. Through assignments, jobs, projects or tasks, professional services clients and providers exchange, generate and utilize information. | Guideline | ||
|
2022-04-15 09:09:24 | Value-based infosec (lien direct) |  This week in an ISO27k Forum thread about selecting information security controls from ISO/IEC 27002, Ross told us "cost is always A factor, however more accurately, the "Cost-Benefit Ratio" may become a deciding factor. A general principle is that the cost of implementing a risk treatment should never exceed the value of the asset being protected. Determining the 'value' of the 'asset' might be tricky (eg. impact to brand value when considering consequential reputational risk), however someone within an organisation often has an existing view on this value."Clearly security controls should save more than they cost, hence in theory organisations should only invest in, operate and maintain controls that are valuable ... but in reality, value-based information risk and security management is far from straightforward.For starters, we have no choice with some controls: even in a greenfield situation such as a high-tech startup, the very act of designing and building the company depends on a raft of governance and managment controlsNext consider the costs. Controls have lifecycles incurring costs at every stage, starting even before we develop or procure them since someone has to determine the requirements, then specify and search for solutions, then implement and configure them. Once operational, there are costs associated with using controls, plus generally they need to be monitored, managed and maintained, and perhaps eventually retired or replaced. Being tricky to measure, it is tempting to ignore these costs, lumping them in with all the other costs of doing business ... which may explain the failure of some kinds of control. Complex controls require significant care and attention to keep them operating efficiently and effectively. Thirdly, consider the benefits. Information security controls rarely eliminate information risks: usually, the best we can hope for is partial mitigation - reducing the probability and/or impact of certain types of incident - and even that is uncertain without associated controls such as monitoring, compliance and assurance. What is the $ value of reducing information risks? If a given control had not been selected and put into operation, how costly would any corresponding incidents |
Guideline | ||
|
2022-04-13 07:25:27 | Domotics - a can-o-worms (lien direct) | [if gte mso 9]> Normal 0 false false false EN-NZ X-NONE X-NONE MicrosoftInternetExplorer4 [if gte mso 9]> | |||
|
2022-04-05 17:31:41 | Infosec control attributes paper completed (lien direct) |  Yesterday, I completed and published the white paper on information security control attributes. Today I drafted a set of comments on ISO/IEC JTC 1/SC 27's proposed Preliminary Work Item for ISO/IEC 27028, using content from the white paper to build a 'donor document' with fairly minor changes in accordance with ISO's rquired structure and format. It includes the following summary: "This document extends the concept of 'control attributes' introduced in ISO/IEC 27002:2022, discussing a wider variety of factors potentially worth bearing in mind when considering, selecting, designing, using and reviewing information security controls. Control attributes are a powerful and flexible tool for information security management purposes, a novel way to design, manage and improve an organisation's approach to mitigating unacceptable information risks, supplementing more traditional or conventional methods. The document includes pragmatic suggestions on how to make use of control attributes in the business context, with a worked example illustrating the approach." Once the comments are submitted, we must wait patiently to see how much of it (if any!) makes it through to the Working Draft, blended with inputs and comments from other committee members. Although it seems to take 'forever' to develop new standards, I'm hoping that the donor document will set the project off to a flying start.Meanwhile, I'm actively looking for opportunities for clients to start using control attributes as an integral part of their ISO27k information risk and security management activities - designing better, more relevant and meaningful security metrics for instance. If that or any other ideas in the paper catch your imagination, please comment below or email me (Gary@isect.com). I see a lot of potential business value in control attributes: how about you? |
Tool | ||
|
2022-03-15 16:36:29 | The nine controls ISO/IEC 27002 missed (lien direct) |  Despite the excellent work done to restructure and update the standard, I still feel some commonplace 'good practice' information security controls are either Missing In Action or inadequately covered by ISO/IEC 27002:2022, these nine for example:Business continuity controls, covering resilience, recovery and contingency aspects in general, not just in the IT security or IT domains. ISO 22301 is an excellent reference here, enabling organisations to identify, rationally evaluate and sensibly treat both high probability x low impact and low probability x high impact information risks (the orange zone on probability impact graphics), not just the obvious double-highs (the reds and flashing crimsons!). Therefore, '27002 could usefully introduce/summarise the approach and refer readers to '22301 and other sources for the details.Availability and integrity controls supporting/enabling the exploitation of high-quality, up-to-date, trustworthy business information and opportunities for legitimate purposes within the constraints of applicable policies, laws, regulations etc., even when this means deliberately taking chances (accepting risks!) to secure business opportunities. Also, I'd like to see, somewhere in the ISO27k series, clearer advice on how to tackle the trade-off between control and utility: information that is too tightly secured loses its value, just as it does if inadequately secured ... and that in turn leads to the idea of at least mentioning financial and general business controls relating to information risk and security (e.g. budgeting, project investments, resourcing, cost accounting, incident and impact costing, valuing intangible assets, directing and motivating specialists: these are all import but tricky areas, so advice would help improve the effectiveness and efficiency of information security). [Some of this is covered, albeit quite academically rather than pragmatically, in ISO/IEC 27014 and '27016, and outside the ISO27k realm.]Health and safety controls protecting 'our most valuable assets', providing a supportive work environment that is conducive to getting the most out of our people, and ensuring the safety of our customers using our products. As with business continuity, H&S is pretty well covered by other standards plus laws and regs ... although, arguably, there's much more left to say, yet, on mental health (e.g. the long-term adverse health effects of excessive stress, both on and off the job), with significant implications for information risks |
Guideline | ||
|
2022-03-14 20:24:00 | Information risk and security management reporting (lien direct) |  Last Thursday, a member of the ISO27k Forum launched a new discussion thread with this poser (lightly edited):"Having recently become an ISMS coordinator, I must prepare a monthly report to management. How does one write an information security report? What should be reported?" Over the weekend we've raised and debated a bunch of ideas, such as a tiered approach, starting at the detailed operational level with effectiveness metrics for the selected information security controls, then aggregating and summarising information for less frequent reports to higher management, emphasising the business perspective (e.g. reporting not just the number of incidents, but a breakdown by severity level mapping to business impacts for senior management). [if gte mso 9]> Normal 0 false false false EN-NZ X-NONE X-NONE MicrosoftInternetExplorer4 [if gte mso 9]> |
★★★ |
To see everything:
Our RSS (filtrered)
