Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

ISACs Demystified
Newest First  |  Oldest First  |  Threaded View
User Rank: Strategist
3/26/2015 | 9:30:08 AM
redefining boundaries and walls....
I commented earlier on this thread about the need for some Gov led action in regards to forcing cyber threat information sharing among private entities and governments.    I read on the way in to work this morning that a bill introduced on Tuesday "Protecting Cyber Networks Act" will "make it easier for companies to share information about cybersecurity threats with the government, without the fear of being sued."

The proposed bill would create an environment for private to private and private to government sharing of threats where the private organisations are indemnified and held free from harm in regards to the threats they are sharing.

However, there is no onus placed on anyone to actually do anything about the sharing of such information.   As such there are a few questions that are raised regarding intent and effect.
  • Is this a pre-cursor to a more heavy handed approach where info sharing will be mandated in the event of breach?
  • Bad guys share information more readily - there is less concern about loss of IP on the "dark side".   Will private corporations actuall share info that could expose them, or other organisations to risk?
  • Will the scrubbing of intel make it less useful?

In the article spawning this comment DSIE Vice Chairman Mike Gordon states pretty clearly that scrubbed info is less useful than un-scrubbed.   The bill seems to propose a sanitised version of what DSIE is already trying to achieve - trying to clean and scrub (a human task which may or may not end up being automated) could result in the creation of a lot more bad data which exacerbates the initial problem of too much stuff to analyse.  

I would still contend that culturally the fear of losing protection of our info is still greater than the fear of that same private data actually being corrupted.   Either the balance of fear will need to change or legislative action will need to be taken to enforce sharing of relevant useful info.

User Rank: Ninja
3/13/2015 | 1:04:37 PM
Re: Seems like we're redefining boundaries and walls?
I like your idea, if the company breached once there has to be mandate to make sure there is a proper team in place and their policy and procedures are under review and they get a grading out of that, how we do it for the restaurants in US currently. That will make most of us secure I would think.
User Rank: Ninja
3/13/2015 | 1:01:36 PM
Re: Understanding who to share with
DIB-ISAC (an acronym for Defense Industrial Base-ISAC was created to address an all hazards approach to securing the DIB Supply Chain. accordign to wikia.com/wiki/DIB-ISAC
Defense Security Information Exchange (DSIE) from whitehouse.gov
User Rank: Ninja
3/13/2015 | 12:57:11 PM
Re: Understanding who to share with
Obviously it is not easy not to get confused. :Thank you for clarifying that, DSIE_Membership :--))
User Rank: Ninja
3/13/2015 | 12:54:01 PM
Obviously we can not address everything at the same time, it is good idea to do prioritization with explanation, that is how it works with all the businesses if you want to get things done
User Rank: Strategist
3/13/2015 | 11:08:46 AM
Seems like we're redefining boundaries and walls?
Each ISAC needs to operate in an environment of full trust and coopoeration with each other, a primary reason hackers were (and are) so successful is that they share their info and techniques.   They do so in an environment that has become ever more professional and corporate - while the hacking charter isn't exactly geared towards "good" the ability and willingness for them to network and share info is something that most corporations would give their eye teeth to have internally.

The white hats (in this case each company affiliated to an industry ISAC) have more to lose than the hackers, hence the reason they're being hacked in the first place.   Some of the items highlighted here are alarming in their short-sightedness such as incomplete, non-contextualised information being shared, inaction on the part of recipients with regard to info provided.

Perhaps the focus of the ISAC is wrong? Instead of trying to share threat identification markers (usually post breach) why aren't they searching for their own vulnerabilities and sharing that info... oh yeah, competiive advantage can't be undermined, right...? In other words a distinct absence of trust.

I'd suggest that any company that has been breached and has lost protected information should be compelled by federal law to set up a vulnerability analysis team (or hire one) and have their results shared with ISACs in their own and other industries for the following 5 years.

How quickly would companies tighten up on security measures in the face of having to consistently air their dirty laundry for the next 20 quarters?
Kelly Jackson Higgins
Kelly Jackson Higgins,
User Rank: Strategist
3/13/2015 | 10:04:32 AM
Re: Understanding who to share with
Thanks, @DSIE_Membership, for noting that the DSIE and the DIB-ISAC are separate organizations.  
User Rank: Apprentice
3/13/2015 | 9:00:10 AM
Understanding who to share with
It's easy to get confused as you look for your company's fit amongst the various information sharing organizations such as ISACs and ISAOs. The reality is that almost anyone can start an information sharing organization so it's very important that companies and individuals understand the scope of the sharing team.  Is the scope Regional / National / Global? Is the scope sector specific or cross industry?  How long this group existed and how trusted is the group in the cyber community?  If you would like more information on DSIE please feel send an email to membership at dsie . net

Please note: While the DIB-ISAO/DSIE are referred to in this article as the Defense industrial base ISAC we are NOT affiliated with the new startup organization known the "DIB-ISAC".

I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
How Machine Learning, AI & Deep Learning Improve Cybersecurity
Machine intelligence is influencing all aspects of cybersecurity. Organizations are implementing AI-based security to analyze event data using ML models that identify attack patterns and increase automation. Before security teams can take advantage of AI and ML tools, they need to know what is possible. This report covers: -How to assess the vendor's AI/ML claims -Defining success criteria for AI/ML implementations -Challenges when implementing AI
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2022-09-24
The secp256k1-js package before 1.1.0 for Node.js implements ECDSA without required r and s validation, leading to signature forgery.
PUBLISHED: 2022-09-24
Nepxion Discovery is a solution for Spring Cloud. Discover is vulnerable to SpEL Injection in discovery-commons. DiscoveryExpressionResolver’s eval method is evaluating expression with a StandardEvaluationContext, allowing the expression to reach and interact with Java classes suc...
PUBLISHED: 2022-09-24
Nepxion Discovery is a solution for Spring Cloud. Discovery is vulnerable to a potential Server-Side Request Forgery (SSRF). RouterResourceImpl uses RestTemplate’s getForEntity to retrieve the contents of a URL containing user-controlled input, potentially resulting in Information...
PUBLISHED: 2022-09-24
Jodit Editor is a WYSIWYG editor written in pure TypeScript without the use of additional libraries. Jodit Editor is vulnerable to XSS attacks when pasting specially constructed input. This issue has not been fully patched. There are no known workarounds.
PUBLISHED: 2022-09-24
Besu is a Java-based Ethereum client. In versions newer than 22.1.3 and prior to 22.7.1, Besu is subject to an Incorrect Conversion between Numeric Types. An error in 32 bit signed and unsigned types in the calculation of available gas in the CALL operations (including DELEGATECALL) results in incor...