Comment Re:Plausible based upon server names...update (Score 1) 302
Just an update....Teradata is usually used as a DWH solution.
Just an update....Teradata is usually used as a DWH solution.
I am working for a Relatively Large Teleco in Europe and can say from the list of server names that this is a plausible hack.
Whether or not however they have real information or just DNS entries however is yet to be seen.
What is the basis for this conclusion?
protib02 Prod IHAP TIBCO 582 Tibco 10.1.81.21 HP-UX 11.11 BOTHELL_7 582 #N/A 1 - Tibco. An application layer messaging bus used heavily in FAB (Fulfilment Assurance Billing) area of large telecos
proetl02 Prod IHAP Teradata 576 teradata 10.133.17.51 HP-UX 11.11 NEXUS #N/A #N/A 1 - Teradata.... another product I know we are using (unknown however exactly what it does)
prowac06 Prod IHAP EAI 151 EAI - Middleware 10.1.80.91 HP-UX 11.11 BOTHELL_7 151 #N/A 1 - EAI - Middleware application used also in telecos.
Similarly the SAP Naming convention used roughly translates to some deployments I have seen in the past.
What does this whole thing give away....
Looking at the naming conventions they have three "defined" network zones:
TAMPA - Management (HP OVO, DNS, Backup Servers)
BOTHELL - Application Server zone with all sorts of stuff. Big flat topology....(ugly with lots of different services using the same subnets and DB Servers not seperated from AS)
NEXUS - Another Application Server Zone with a mix of stuff within it. This appears smaller and newer than the other from the server names.
What does this show from a security perspective?
- No clear Security Architecture
- No clean separation of Backup network (backup mixed with Management functions... this should be in a seperate network).
- No clean separation of Management Network (SAN/Backup/OVO located together)
In any Teleco situation with thousands of servers it is impossible to prevent a security breach. There is always going to be servers somewhere which are unpatched, legacy, forgotten etc.
What is important is a "defence in depth" principle to limit any disclosure. In this instance that appears not to have been followed. The topology is "Flat" with an emphasis on easier communications between systems rather than minimizing communications to minimum required. This essentially stopped any chance of them being able to limit a breach.
Hopefully someone will get some lessons learned out of this. I know I will be presenting some points to our management where we should be focusing based upon this. Our security is definitely better but nothing is perfect.
I'm interested in any points that anyone else could offer here, I have not discussed all points however I am interested in the perspective of others from what they can mine there.
Please more comments!
http://streetstyles.ch/ - Schweiz Band & Fashion Tshirts
Live within your income, even if you have to borrow to do so. -- Josh Billings