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.

Comments
ISACs Demystified
Newest First  |  Oldest First  |  Threaded View
jamieinmontreal
50%
50%
jamieinmontreal,
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.

 
Dr.T
50%
50%
Dr.T,
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.
Dr.T
50%
50%
Dr.T,
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
Dr.T
50%
50%
Dr.T,
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 :--))
Dr.T
50%
50%
Dr.T,
User Rank: Ninja
3/13/2015 | 12:54:01 PM
Prioritization
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
jamieinmontreal
50%
50%
jamieinmontreal,
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
100%
0%
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.  
DSIE_Membership
100%
0%
DSIE_Membership,
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".


News
A Startup With NSA Roots Wants Silently Disarming Cyberattacks on the Wire to Become the Norm
Kelly Jackson Higgins, Executive Editor at Dark Reading,  5/11/2021
Edge-DRsplash-10-edge-articles
Cybersecurity: What Is Truly Essential?
Joshua Goldfarb, Director of Product Management at F5,  5/12/2021
Commentary
3 Cybersecurity Myths to Bust
Etay Maor, Sr. Director Security Strategy at Cato Networks,  5/11/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Google Maps is taking "interactive" to a whole new level!
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-21830
PUBLISHED: 2021-05-17
A heap based buffer overflow vulneraibility exists in GNU LibreDWG 0.10 via bit_calc_CRC ../../src/bits.c:2213.
CVE-2020-21832
PUBLISHED: 2021-05-17
A heap based buffer overflow vulnerability exists in GNU LibreDWG 0.10 via read_2004_compressed_section ../../src/decode.c:2417.
CVE-2020-21833
PUBLISHED: 2021-05-17
A heap based buffer overflow vulnerability exits in GNU LibreDWG 0.10 via: read_2004_section_classes ../../src/decode.c:2440.
CVE-2020-21834
PUBLISHED: 2021-05-17
A null pointer deference issue exists in GNU LibreDWG 0.10 via get_bmp ../../programs/dwgbmp.c:164.
CVE-2020-21835
PUBLISHED: 2021-05-17
A null pointer deference issue exists in GNU LibreDWG 0.10 via read_2004_compressed_section ../../src/decode.c:2337.