Anthem Details

Home » CentOS » Anthem Details
CentOS 9 Comments

Hello Everyone,

Does anyone have any more detail about what kind of system Anthem / Blue Cross was running and what kind of attack broke into their system?

It’s terrible that it happened, but I think it would benefit all Admins everywhere to learn how it happened so that we can secure our systems from a similar breach of information.

Anyone know?

Chris

9 thoughts on - Anthem Details

  • I recommend reading up on kreb’s site:

    http://krebsonsecurity.com/2015/02/china-to-blame-in-anthem-hack/

    Not sure the “hack” was an issue with their platforms per se.


    “On January 27, 2015, an Anthem associate, a database administrator, discovered suspicious activity – a database query running using the associate’s logon information. He had not initiated the query and immediately stopped the query and alerted Anthem’s Information Security department. It was also discovered the logon information for additional database administrators had been compromised.

    SANS is a good resource as well.

    I’m no security expert by any means, so ymmv.

    Regards,

    Monty

  • Flash has always been banned from all my machines, without exception and regardless of any resulting “hardship”. I wonder why so-called Computer Experts continue to use third-party closed source software which secretly, and it always has, deposits information on the user’s hard disk.

    Another Lesson to learn:

    *NO* Flash stronger passwords for SQL
    encrypt all the data that is not required for indexed searches.

    There is a war going-on out there and we are the targets !


    Regards,

    Paul. England, EU. Je suis Charlie.

  • At least this I would change in your list:

    Do not use crappy software, no matter how nicer your life with it becomes.
    (Except maybe piece of junk computer you are not using for anything of value). Not just flash but any poorly written software.

    Flash was piece of crap code when it was originally written. Even before original programmers were wrestled out of owning it. I didn’t see closed source code, but there always are indications you can observe. One of the indications of poorly written code was: it was written not portably, just for 32 bit (i386) systems. Why I’m saying that? Remember how long flash player/plugin was purely 32 bit binary, even though everything was 64 bit for quite long time already? Adobe even admitted they have to significantly re-write it before they can release 64 bit? and first 64 bit binaries were bad, they didn’t re–write code from scratch, but tried to modify… Of course there is more about flash media file standard itself…

    For those who doesn’t program, portable in this case means: you can define sizes of variables (in bytes) using plain numbers (valid for given architecture, say, i386) when defining variables. Alternatively instead of number, you can use (sizeof(integer)) or (sizeof(string). Then the code can be compiled on different architectures and will have correct sizes of variables for given architecture/ CPU word length (sorry, if name CPU word is not correct – that is what we called it back then…). I just randomly searched and this may give you good feeling of what I meant:

    http://www.delphibasics.co.uk/RTL.asp?Name=SizeOf

    Anyway, one more lesson: avoid using poorly written software (even if these are only indications of it being written poorly that you can observe).

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • the hackers had the database administrators user account credentials, and were coming in through the VPN via said credentials. I doubt stronger passwords would have mattered.

  • Hmmm, maybe a reasonable argument for the crypto-card type VPNs where the passwords aren’t reusable…

  • indeed, my $job uses an RSA token based authentication for the VPN, but internal host access uses simple username/password.

  • Excellent suggestion especially as the current ‘defences’ failed. Rather senseless for some to rely so enthusiastically upon the existing failed protection.

    Definitely +1 for that good and safer idea.

  • Two factor authentication is really what one needs for all servers providing secure services: i.e something you know and something you possess Google does this via a password (known) and a key txt’d to your cell phone (something you possess). Simple and quite cost effective as most folk that work on servers are likely to already have a cell phone and it works world wide. I haven’t checked if Google offers an API for this, but sending txt messages from a server must not be that difficult to achieve. Another task for my scantly available spare time.