ES Episode79

From Paul's Security Weekly
Jump to: navigation, search

Enterprise Security Weekly #79

Recorded February 7, 2018 at G-Unit Studios in Rhode Island!

Episode Audio


Hosts

  • Paul Asadoorian
    Embedded device security researcher, security podcaster, and CEO of Active Countermeasures .
  • Doug White
    Cybersecurity professor, President of Secure Technology, and Security Weekly network host.
  • Interview: Summer Fowler, InfoSecWorld Speaker

    Summer Fowler is the Technical Director of Cybersecurity Risk & Resilience in the CERT Program at Carnegie Mellon University's (CMU) Software Engineering Institute (SET). Summer is responsible for a research and development portfolio focused on improving the security and resilience of the Nation's critical infrastructure and assets. Summer has 17 years of experience in software engineering, cybersecurity, and technical management.
    Prior to joining the SEI, Summer was a Technical Member at Johns Hopkins University Applied Physics Laboratory and a software engineer at Northrop Grumman Corporation.
    Summer holds a BS degree in Computer Science and a MS degree in Information Science/Telecommunications from the University of Pittsburgh. Summer teaches two graduate level courses on Information Cybersecurity Policy at the CMU Heinz School.


    Enterprise News

    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180129-asa1
    First and foremost, Cisco released another vulnerability in the ASA on Sunday. So, maybe you were watching the superbowl while we worried about our ASAs. Cisco had released a vulnerability for the ASA previously but released a further notice on it on Sunday https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180129-asa1

    1. Basically, it's a remote code execution vulnerability in the XML parser so obviously you may want to firewall your firewall or something like that. You shouldn't have to harden a firewall

    but the reality is, that you should definitely be doing just that. Security is about layers, as you well know, so don't start assuming that one device or another is going to be invulnerable.

    1. Cisco finalized the patches of the XML Energywise vulnerabilities for that DOS from last year. Be sure and get those patches in place.

    https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170419-energywise

    1. SANS announced that there is an Adobe Flash vulnerbility being exploited zero day in Korea. Apparently, this is part of the latest Jan release and the patch Tuesday.

    The exploit can be embedded in Microsoft Office or web pages. The recommendation is to disable or uninstall flash player. Advisory CVE-2018-4878 was issued that the exploit would be patched in the "next weeks"

    [Two minute rant about deep freeze and the need to apply prod dev methodology to desktops. Basically, we don't apply good hygiene to much of anything and the traditional prod dev process is not really realistic in the modern age where a vulnerability a minute is popping up. I mean can you really have a full analytic process which decides that version 17.5 is safe and then lock it down and when four hours later version 17.5 is replaced with 17.6.1.101 which is then replaced by nightfall with 17.6.2.10067 which is found to contain a vulnerability within minutes by the South Korean girls handbell and hacking club? I mean seriously, the old prod dev model which we attempt to use is too time consuming to really be useful if we are going to see the time horizon down to hours on everything. I mean, we could all still be running Win XP on our desktops if that happens. You aren't still running XP are you? NT 4.0? So, what to do. I kind of think prod/dev (which should still be in place for development understand) is not the panacea for everything. I know, I know, I have been advocating it for years but I think it's the philosophy more than the method and that's what got us in trouble. Techs like me said "prod dev" when the accountants asked what should be done and we were thinking philosophy and you can't do that with accountants. Security in layers is another one. I said that to an Accountant once and he said "ok, how many layers should there be when we test?" I really think if I had said "three, shall be the number of the counting, four shall thou not count..." well, today everyone would be required to have three layers of security. So, really, we can't apply prod dev to the desktop environment and instead have to rely on hygiene and layers. The other thing is there almost has to be a way to get CERT type information in place so you really need a security officer who just reviews and restricts on the fly. ]

    1. Speaking of hygiene, a new variant of Scarab tells you it will shred 24 documents every day until you pay, and apparently it starts mailing pieces of the documents to you in the US mail

    (that last part I made up). I hate to tell you this but your users are going to download this stuff so, just to reiterate, out of band backups people. https://www.computing.co.uk/ctg/news/3025974/new-variant-of-scarab-ransomware-threatens-to-shred-24-documents-every-day-until-you-pay

    [Rant about End users: So, basically, what is going to happen is you can spend 96 billion dollars on security (per Gartner) in 2018 and it's still going to come down to Robin in Marketing downloading infected porn or Chris in the warehouse clicking that dirty link. I do think we have to focus on the layer of security that really pushes the training button for the end user and the IT people. I mean, we are the worst abusers with the most privilege in the enterprise so even there. I found it's really tough to train people because stupid people never think they are stupid and smart people are often even stupider then stupid people because the stupid people at least may have started to suspect they maybe aren't quite up to speed while the smart people are busy being condescending to the stupid people and click that whitehouse.com link during their major presentation, not that that ever happened to me or anything. So, it seems that maybe our training needs to be reviewed in the sense that we keep telling everyone not to click that link and everyone keeps clicking the link. ]

    There also seem to be partnerships starting to form by the big guys. Apply, Cisco, Allianz, and Aon partner in Cyber Risk Management. A group developed tool for risk management of ransomware is on the way with Apple and Cisco coding the technical foundation (see, #1 above). I think this all kind of starts being the basis for underwriting. If Allianz is going to underwrite you for ransomware then they may require you to run this risk tool on your systems to be in compliance. According to Cisco, you will have a "streamlined fcyber risk evaluation from AON". Then you implement Cisco Ransomware Defense on your systems (hopefully not with XML zero days) and you will use Apple devices. This would let you qualify for "enhanced cyber insurance" from Allianz. The bundle is apparently also getting "IT Team readiness and response in case of a breach". This is apparently available now in the US. https://blogs.cisco.com/security/an-industry-first-a-better-framework-for-cyber-risk

    1. APIS Post Mushrooming Security Risk -- as if that was news. But, it's a good point. Let's talk about two things in this bit. APIs and AI. I have long said that there is a very big

    danger in what I used to call chimera coding. Back in the day, if you wrote the code soup to nuts, you at least knew what was in there (I know, you kids today and your fancy apis, get off my virtual lawn). But that's true. If I code it, I own it, and I probably have to fix it when it breaks. That's not really possible any longer unless you are just trying to put hello world on the screen (and probably not even then, cout << "hello world" << endl;) As we move forward with APIS and they become the basis and bane of our coding existence, like most other things we shift into the world of "users" and out of the world of developers. There used to be a term "middleware" and in some ways we have all become middleware. So, if I take ten apis and use them as a foundation library of the code I write and then bolt 15 more on in the dev...well, starting to see the problem? Now, you as a security officer or CISO or whatever you are, have to take that giant bundle and somehow are supposed to assess that it is clean. Good luck. Let's add AI to the mix. As we see the rise of the machines (and just remember Wintermute, I was here inm Villa Straylight welcoming you first), if AI starts coding (and it is) and begins coding new APIS faster than we poor humans can follow them, what's in those APIs exactly? Does an AI perceive threats the same way I do? Hopefully, the AI will code an API that will swat phishermen like bugs with some killer bots but even then, if our code is 80 gig of APIS bolted together and we added that one giant api just so we could use mod command, it's going to be a challenge like we have never seen to try and evaluate the risk contained in the back office library. Not to mention is version 101.110007.109.A.17 safer than .16? Maybe AI eval is going to be the next big thing. If an AI can evaluate the api, that might be a cool idea. http://threatbrief.com/apis-pose-mushrooming-security-risk/

    1. Mastering Security in the Zettabyte Era. Global internet traffic will be 95 times greater than in 2005 when it was just me and a guy named Sid complaining about users. This combined with

    big data, AI, and seven Nigerian scammers, creates a threat like never before to your enterprise. Of course, it also provides massive opportunity to develop new products to deal with all this which leads to more threats. It's a mad, mad, mad, mad, world. Enjoy the ride.


    Follow us on Twitter Watch Security Weekly videos Listen to Security Weekly Security Weekly fan page Connect with Paul Google+