This past week, I was part of three state agency firedrill around a failed web service.
The web service failed at 12:16 PM on Tuesday 8/25/2009. I know this because I got one of the red colored emails from State of Colorado Judicial. Our side is the client, the server is Judicial.
I tried, with little success to get the interest of my manager, his manager, the network admin, anyone who would talk to me. At the state today, there is little downtime. Everyone's resources are stretching a little further every day, when you think that you just can't stretch anymore. All of the people that I tried to talk to had other priorities. At the end of the day, I didn't have an answer about what was happening, and the Judicial IT guy was not happy.
He complained up the line, and at the very very end of the day, we had top management from three agencies asking for answers.
The next day, after some venting had happened, we began to investigate. I defended, quite strongly I might add, that the code was not to blame, that the last production move we made had been successful and was not related to the present problem.
Judicial began to send us shots of their side, the firewall logs, that indicated that they were not the problem.
Just as we were about to do some real time monitoring of the web service transaction, just as I had been talked into adding even more error handling into the application, just at that moment, the system started to work again. It was 10:47 AM, Wed, 8/26/2009.
Now, I would have been looking to place the blame, except for one fact. During the time of the outage, there were about 75 records that were sent. Of that number, 4 records got through. The problem was intermittent. It was neither fully broke or fully functioning. This fact got in my way of placing responsibility on the party who caused the problem.
In the process of writing the textbook for Transport Layer Security this weekend, I came across an article that may have some relevance to this problem. The article was at Microsoft, http://msdn.microsoft.com/en-us/library/aa480583.aspx. This article talks about "One liability ... is that firewall boundaries may not allow Kerberos authentication traffic between the calling application and the Kerberos Key Distribution Center (KDC) or between Web service and the Kerberos KDC." This describes a possible scenario that could have caused our outage this week. I still don't know whose firewall is not configured correctly, but I am quite sure that is it not my code.
Sunday, August 30, 2009
Saturday, August 29, 2009
17th National HIPAA Summit
The 17th National HIPAA Summit will be held in Washington DC from 9/15/09 - 9/18/09.
Subjects to be covered include:
Private changes in the Stimulus package
CMS Security Audits
CMS and NIST Security Recommendations
Health Information Privacy and Security Collaboration
ICD - 10 Requirements and Preparation
Transactions and Code Set Modifications
Claims Attachments
Implementation Strategies and Challenges for the HIPAA Regulations (this is the one we have all been waiting for)
Enforcement
Also interesting is the list of sponsors.
http://www.hipaasummit.com/
Subjects to be covered include:
Private changes in the Stimulus package
CMS Security Audits
CMS and NIST Security Recommendations
Health Information Privacy and Security Collaboration
ICD - 10 Requirements and Preparation
Transactions and Code Set Modifications
Claims Attachments
Implementation Strategies and Challenges for the HIPAA Regulations (this is the one we have all been waiting for)
Enforcement
Also interesting is the list of sponsors.
http://www.hipaasummit.com/
SQL Injection attacks and DNS
Hi, I'm still on SQL Injection attacks.
This article puts a new spin on the problem:
http://www.networkworld.com/news/2009/082709-sql-attacks-linked.html?hpg1=bn
Three waves of SQL attacks have created botnets of 80K in China, 67K in US and 40K in India (must be all those good Indian computer people that are keeping their country safer).
The attacks have expanded their scope by adding frames to legitimate websites that redirect the user to a "mal-domain", coined by senior security researcher at ScanSafe, Mary Landesman.
Seven domains have been identified as the orignation point of the attacks. All seven domains are owned by the same gibberish named account. This happened because registars allow domain name registration by automated process.
Landesman says "We have a system that allows people to provide completely bogus details about who they are".
So the author of the SQL Injection attacks is not only technically savvy, but uses the flaws in the registars' system to proliferate new websites to launch attacks against China, US and India. Let's see, who does that leave? Maybe its coming from the Russians.
Its not just the openness of the automated domain name registration system, but the lack of any effective oversight. These criminals are opening malware websites right in the open, with no checks.
This article puts a new spin on the problem:
http://www.networkworld.com/news/2009/082709-sql-attacks-linked.html?hpg1=bn
Three waves of SQL attacks have created botnets of 80K in China, 67K in US and 40K in India (must be all those good Indian computer people that are keeping their country safer).
The attacks have expanded their scope by adding frames to legitimate websites that redirect the user to a "mal-domain", coined by senior security researcher at ScanSafe, Mary Landesman.
Seven domains have been identified as the orignation point of the attacks. All seven domains are owned by the same gibberish named account. This happened because registars allow domain name registration by automated process.
Landesman says "We have a system that allows people to provide completely bogus details about who they are".
So the author of the SQL Injection attacks is not only technically savvy, but uses the flaws in the registars' system to proliferate new websites to launch attacks against China, US and India. Let's see, who does that leave? Maybe its coming from the Russians.
Its not just the openness of the automated domain name registration system, but the lack of any effective oversight. These criminals are opening malware websites right in the open, with no checks.
Sunday, August 23, 2009
SQL Injection attacks are the news this week. In one article (http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1365263,00.html?track=sy160), I read:
"the fact that only now has the software development lifecycle started to mature to the point where developers have enough security skills and keep security in mind when they build applications"
I am not sure that I agree with this statement as the reason why there are so many SQL injection risks. I have worked with several contractors from India who put mass quantities of hard coded SQL statements into code. I have done code reviews where I stated "This needs to be taken out, and this and this" etc. I know of one application that was written by contractors that took 2 people 1 year to replace all the hard coded SQL (of course, it is the State, but these were dedicated developers).
SQL injection attacks are all due to hard coded SQL. No code should ever include hard coded SQL statements, not even one! Now we have learned, and now we review all code and will reject anything like this. However, the contractors are still writing this way, so unsuspecting customers who like to use contractors can still end up with spaghetti code and big risks of SQL injection. It may be going to far to call it malicious, but it certainly leaves a back door open.
"the fact that only now has the software development lifecycle started to mature to the point where developers have enough security skills and keep security in mind when they build applications"
I am not sure that I agree with this statement as the reason why there are so many SQL injection risks. I have worked with several contractors from India who put mass quantities of hard coded SQL statements into code. I have done code reviews where I stated "This needs to be taken out, and this and this" etc. I know of one application that was written by contractors that took 2 people 1 year to replace all the hard coded SQL (of course, it is the State, but these were dedicated developers).
SQL injection attacks are all due to hard coded SQL. No code should ever include hard coded SQL statements, not even one! Now we have learned, and now we review all code and will reject anything like this. However, the contractors are still writing this way, so unsuspecting customers who like to use contractors can still end up with spaghetti code and big risks of SQL injection. It may be going to far to call it malicious, but it certainly leaves a back door open.
Saturday, August 22, 2009
In the past two weeks, I have been assigned 2 VMWare tasks, one at work and one here at school. At work, one VERY overworked network guy gave me a 10 minute introduction to VMWare as in "Here's how you log in, here's your password, let me know if you have any questions." I did go through the training videos on it at http://www.vmware.com/products/labmanager/tutorials.html. I am looking forward to working with VMWare for this class.
I went to secunia.com (I like their maps), and looked at their recent advisories. One of them is for VMWare, http://secunia.com/advisories/36389/.
I wonder what new security risks VMWare will pose? The technology appears to me to be the future.
I went to secunia.com (I like their maps), and looked at their recent advisories. One of them is for VMWare, http://secunia.com/advisories/36389/.
I wonder what new security risks VMWare will pose? The technology appears to me to be the future.
Wednesday, August 19, 2009
Subscribe to:
Posts (Atom)