Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security Government

HP Enterprise Let Russia Scrutinize The Pentagon's Cyberdefense Software (reuters.com) 121

"A Russian defense agency was allowed to review the cyberdefense software used by the Pentagon to protect its computer networks," writes new submitter quonset. "This according to Russian regulatory records and interviews with people with direct knowledge of the issue." Reuters reports: The Russian review of ArcSight's source code, the closely guarded internal instructions of the software, was part of Hewlett Packard Enterprise's effort to win the certification required to sell the product to Russia's public sector, according to the regulatory records seen by Reuters and confirmed by a company spokeswoman. Six former U.S. intelligence officials, as well as former ArcSight employees and independent security experts, said the source code review could help Moscow discover weaknesses in the software, potentially helping attackers to blind the U.S. military to a cyber attack. "It's a huge security vulnerability," said Greg Martin, a former security architect for ArcSight. "You are definitely giving inner access and potential exploits to an adversary."
It's another example of the problems security companies face when they try to do business internationally, according to Reuters. "One reason Russia requests the reviews before allowing sales to government agencies and state-run companies is to ensure that U.S. intelligence services have not placed spy tools in the software."

Long-time Slashdot reader bbsguru has his own worries. "So, opening your code for review because it is demanded by a potential customer? What could possibly go wrong? HPE may find out, and the U.S. Military is among the many clients depending on the answer."
This discussion has been archived. No new comments can be posted.

HP Enterprise Let Russia Scrutinize The Pentagon's Cyberdefense Software

Comments Filter:
  • by Xenographic ( 557057 ) on Saturday October 07, 2017 @05:39PM (#55328827) Journal

    Wait until they figure out who all Microsoft has shared the Windows source code with.

    • Re: (Score:2, Troll)

      Do they even have source code? I thought it was all chewing gum, baling wire, and gerbils....

      • Keep laughing. Wait until Poettering dreams up this new brilliant idea. Instead of having /etc and its collection of human readable text files, all system configuration settings will be kept in a binary database named REGISTRY.DAT. Redhat will love this because their business model is selling support.

    • Re:Ordinary (Score:4, Interesting)

      by fibonacci8 ( 260615 ) on Saturday October 07, 2017 @07:50PM (#55329263)

      Wait until they figure out who all Microsoft has shared the Windows source code with.

      Or Linux, just look at who they share the source code with!

    • by Anonymous Coward

      Security through obscurity doesn't work. Fuzzing will eventually find holes.

      It is time to change policies toward open source software. This approach puts security in everyone's best interest.

      It is also time to switch to IPv6 only.

      It is also time to get critical infrastructure completely off of the Internet.

  • by Kaenneth ( 82978 ) on Saturday October 07, 2017 @05:39PM (#55328829) Journal

    A good security product is secure even if attackers know how it works.

    • That's why side-attacks are so unsuccessful, right? No one could figure out a methodology to spoof the good guys, right? NSA-- never been hacked, right?

      IMHO, HPE should be hung out to dry.

      • by Anonymous Coward on Saturday October 07, 2017 @06:36PM (#55329043)

        If your bank is only secure as long as no one is allowed to see you handle the money, you don't have a very secure bank.

        If your software is only secure as long as no one is allowed to see it handle input, then you don't have very secure software.

        FYI: Saying that your protection is a smokescreen and magic hand waving is not as good as having good documentation detailing what the protection's limits are and where improvements can be made. The latter can be implemented with those

        • by Anonymous Coward

          Damn phone...

          The latter can be implemented taking those deficiencies into account, the former can only hope that it holds up when it's needed most. (And isn't compromised at the time of purchase.)

          • Your metaphors are as foolish as you are. Good grief. It's inferred that various actors used Kaspersky's AV-AM to have a full inventory of an NSA contractor's purloined (oh, sure, he was working at home) software.

            ArcSight isn't impregnable. Side-channel and other methods of getting the keys to the Pentagon are a VERY BAD IDEA if you're an American.

            Remember the Axis of Evil? Do you think that Russia has reformed? What brought you to that conclusion, if so? What HPE did may have been "legal", I'll grant you,

    • by Anonymous Coward

      There's a big difference between relying on obscurity for your security, and making your enemies jobs harder.

      I'd never trust a cypher that isn't published and properly reviewed. It's far too easy to make a mistake designing or implementing encryption systems, and the encryption community are very good at rooting out bad ideas and bad code.

      However, there's no need to be open about which open tool you're using.

      Lets say I encrypt a file, and send it to you without the key. It's basically random bytes, and you

      • Many people think in an a mutually exclusive way. EITHER a secure tool, OR a system using obscurity. Good security systems employ both. Lock it with the best tools that can be found, AND obscure all the details.

        What is described sounds just fine. A security company revealed their source code to be used by a government to show it is backdoor-free. That's typical in the security industry, and is generally not inherently a problem. The organizations should, as you described, not tell the world exactly whic

    • by stooo ( 2202012 )

      Yep,
      I second that. Obscurity doesn't work for security.
      Furtnermore, a good security product can only become good when the source is reviewed by many many parties.

  • Citizenship vs capitalism.

    HPE acts like it doesn't have the sense god gave a pissant, but, sadly, it does.

  • So you're in favor of "security through obscurity".

    I can't say that that's in any way a good technical argument.

    You share code with the Russians, their people look at it, and suggest changes before they are willing to buy it.

    You share code with the U.S. government, their people look at it, and suggest changes before they are willing to buy it.

    Everyone wins.

    • You're serious?

      How about: their people look at, come up with some changes they'd need before trusting their systems to it, then give one back to the vendor and keep some to themselves for later.

      COTS is the devil when it comes to American defense procurement. Yeah you don't need to commission a new programming language and compiler for every single solitary project like they had to do back in the 70s and 80s, but then at the same time you don't really want to be buying an OS from a company where the single
      • by Tom ( 822 )

        How about: their people look at, come up with some changes they'd need before trusting their systems to it, then give one back to the vendor and keep some to themselves for later.

        Yes, the "threat model" is that they discover a bug and don't tell anyone.

        Which means that the NSA (who is responsible for keeping US government infrastructure and systems safe) didn't find that bug when they did their source code review.

        Additional information: There are many ways to find bugs in software aside from code reviews. So not showing them the code would have had two effects: a) they would've probably bought some other software and b) they would've given the binary to their binary testing team.

        • by RightwingNutjob ( 1302813 ) on Saturday October 07, 2017 @08:40PM (#55329397)
          Source code can contain information the binary doesn't. Like why mistakes are made and who made them, to give an example. So if there's an exploit in the binary, you find it either way. If the source code with the mistake contains comments from Sanjay at CompuGlobalHyperMegaNet in Mumbai, that tells you where else that mistake could be. If there's no mistakes in Sanjay's code, you still have a potential recruitment target. Paranoid? Yes. Unlikely? Can't say. Implausible? No.
          • by Tom ( 822 )

            It is possible to remove comments from source code before handing it in to code review.
            It is also possible to establish sane comment guidelines, especially when you are a security company.
            And it is quite trivial to figure out who actually writes the software for a software company, without comments in source code.

            Sure you get additional information from code, especially if good documentation explains the thinking behind algorithms. However, to go into a panic because another country made a source code revie

            • I'm not going into a panic because another country is doing source review. I'm saying the US government shouldn't be using code that's neither open source nor fully closed source. If it's fully open source, everything I said doesn't matter because it's got more eyeballs on it. If it's fully closed source and only domestic users review it, then that attenuates the risk. This here is a no-man's land in between where you don't get any of the benefits and have to assume that everyone's got their thinking hats o
              • by Tom ( 822 )

                I'm saying the US government shouldn't be using code that's neither open source nor fully closed source.

                While there are theoretical advantages to Free Software in this context, they do not manifest to the degree that many Free Software advocates think. And I say that as a stern believer in Free Software (to the degree that I refuse to call it "Open Source").

                OpenBSD is about the only project that actually does this right - by not relying on the assumption that Free Software actually gets read, but making sure it happens and running regular code reviews.

                From a security perspective, I'd rather take a piece of cl

        • I think code review is unlikely to discern mistakes at the scale of a large piece of software.

          On the other hand, breaking up the chunks of the monolithic application into pieces to do unit testing can presumably make fuzzing easier. So the ability to re-build the project in a different way can be helpful.

    • by Anonymous Coward

      Obscurity can be a perfectly valid defense layer for an attacker, so I'm not sure why you think there's no technical argument for it.

      Tanks have armor, but they are often painted to match their terrain to obscure their location. Painting the vehicle does nothing to harm the armor, and it does help prevent targeting by the enemy -- through difficulty to see on reconnaissance. Invisible tanks would be even better.

      By allowing an enemy to see government-run computer code, we're not only identifying what syste

      • The higher the standards of security, the more we need FOSS, because it's the superior security model. If you need it with zero bugs, you write it in something like Ada Spark.
      • Obscurity can be a perfectly valid defense layer for an attacker, so I'm not sure why you think there's no technical argument for it.

        The real equivalent to camouflage paint on the Internet is to not show up on nmap and other port scans. That's not obscurity, that's not offering an unnecessary attack surface -- just as with tank visibility against backgrounds.

        I guarantee you that the desert camouflage stands out like a sore thumb in Leningrad in the winter.

        You make a terrible assumption that the Russians would TELL the vendor of exploits they'd find as well as bother to use the software internally themselves.

        If the Russians get so far as to sign a letter of intent, in order to get access to audit the source code ...and then decline to purchase ...that's a pretty strong positive indicator o

  • by Rick Zeman ( 15628 ) on Saturday October 07, 2017 @06:15PM (#55328971)

    "The capitalists will sell us the rope with which we will hang them."

    V.I Lenin

  • Why not assure the software is secure and bullet proof to start with? If Russia finds a bug or opening to exploit the US, it only shows the US didn't do it's job in reviewing and securing the software / infrastructure.
  • by Tom ( 822 ) on Saturday October 07, 2017 @06:45PM (#55329065) Homepage Journal

    Sensationalist crap if I ever saw one.

    Making a source-code review is standard operation procedure for high security settings. In fact, I recommend exactly this to some of my clients (I've worked in IS before the abbreviation had a second meaning about murderous religious idiots).

    If this allowed them to discover weaknesses in the software, then maybe the US departments should've done a source-code review themselves and discovered those same weaknesses? What is wrong with the author of this crap to shout wolf because someone is doing proper security?

    "omg, the Russians tested the same rifle that our army uses! Maybe they discovered at what temperature it explodes!"

    Guys, you need to wake up over there before you find yourself plundged into a new Cold War by nonsense propaganda. Ask yourself who profits from such shit, who gets to sell more stuff thanks to articles like this, and who gets to gain more influence from the fear.

    • by chill ( 34294 )

      Exactly. Both Russia and China have demanded -- and gotten -- source code reviews of code from Microsoft, Cisco, IBM, and SAP. This is, and has been, standard practice for over a decade.

      This isn't news, it is sensationalist headline clickbait.

      https://venturebeat.com/2017/06/23/tech-firms-including-cisco-ibm-and-sap-allow-russian-authorities-to-review-product-source-code/ [venturebeat.com] (2017)

      http://www.zdnet.com/article/microsoft-opens-source-code-to-russian-secret-service/ [zdnet.com] (2010)

      https://www.computerworld.com/article/2581 [computerworld.com]

  • 1. Use off-the-shelf product to save money, but another big customer might also audit the code (the current predicament)
    2. Use custom product so it's unavailable to others, but ultimately relying on obscurity
    3. Go open source and have politicians and media have a heart attack about how "now everyone can access the source code / Trump is giving our source code away for free"
    4. Export ban on this software while you use it, again relying on obscurity

  • it shouldn't make any difference who looks at it. Linux and Unix are generally considered more secure than Windows but all the source code is available for anyone to look at.
  • by Anonymous Coward

    Security consultant here with experiences in SIEM's. ArcSight is a security information and event management (SIEM), which means all it does is collecting logs from other security devices together and deciding if sequence of events has higher priority compared to individual event.
    For example, connection from unknown address, crashed antivirus service and unusually high disk activity is likely to be cryptolocker.
    There is nothing valuable in source code of SIEM's, its a bunch of regex to parse incoming logs f

  • Move along, nothing to worry about. It's just arcsight. You're better off using owasp. We have the HP product, it's crap. False positives and they don't listen to customer feedback. Almost as bad as Tenable. They think they know better than the experts, such as the Crypto experts on a vulnerability that was patched almost a decade ago. They don't even follow their own rules and they don't listen to their customers either.

Many people write memos to tell you they have nothing to say.

Working...