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 3 tier architecture DMZ/Application Server/DB Server split. - 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.
I am working in a large firm. Quite often new projects upon realisation require technical audits as well as "Life Cycle" audits for existing systems involved with billing etc.
One point that needs to be clear. Audits are not cheap! These guys are paid between 1500-2000 per Man day. Presently this is done in essence without ANY liability as to the quality of their work.
What needs to be established in this case is:
1. Technical Audits provide a snapshot of a system "at a particular point in time" - Did at the time of the Audit these holes exist, or where there changes afterwards which could have affected the audit results?
2. Audit Scope. This is really important! If the Audit scope didn't include for instance the visibility of the systems from outside of the firewall, then the perspective of the auditors were limited and therefore the audit itself is not complete.
I have seen companies for instance that are ISO 27001 Certified....however.... the audit scope was only for a particular part of the company. This enables the company to suggest 27001 Certification when in fact it may not indeed be fully the case.
Most likely the outcome of such a case would be an increase in costs to cover Liability (insurance or something of the like) on the part of the auditor. However it may well be also an increase in the quality and transparency (clearer scope, limitations etc.) of technical audit work.
Both of these are positive outcomes!
http://streetstyles.ch/ - Swiss Band & Fashion Tshirts
Slashdot Mirror
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 3 tier architecture DMZ/Application Server/DB Server split.
- 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
I am working in a large firm. Quite often new projects upon realisation require technical audits as well as "Life Cycle" audits for existing systems involved with billing etc. One point that needs to be clear. Audits are not cheap! These guys are paid between 1500-2000 per Man day. Presently this is done in essence without ANY liability as to the quality of their work. What needs to be established in this case is: 1. Technical Audits provide a snapshot of a system "at a particular point in time" - Did at the time of the Audit these holes exist, or where there changes afterwards which could have affected the audit results? 2. Audit Scope. This is really important! If the Audit scope didn't include for instance the visibility of the systems from outside of the firewall, then the perspective of the auditors were limited and therefore the audit itself is not complete. I have seen companies for instance that are ISO 27001 Certified....however.... the audit scope was only for a particular part of the company. This enables the company to suggest 27001 Certification when in fact it may not indeed be fully the case. Most likely the outcome of such a case would be an increase in costs to cover Liability (insurance or something of the like) on the part of the auditor. However it may well be also an increase in the quality and transparency (clearer scope, limitations etc.) of technical audit work. Both of these are positive outcomes! http://streetstyles.ch/ - Swiss Band & Fashion Tshirts