Since I am posting something I can only assume I have an assignment due today, let me see... Assignment 1...28th of September... doh! Ah well, better get on with it (writing a post that is).
I am constantly amazed at the lengths developers will go to to guarantee the insecurity of the application thy are writing. The application I am evaluating at work at the moment is a web application that, up until this version, has run atop IIS. Now in all their wisdom the manufacturer has decided it would be a far better idea to write their own web server. But wait it gets better the services for this particular application need to run with local admin rights including the web server. Wait, let me get this straight you want me to expose a custom written web server with who knows how many buffer, stack and heap overflow vulnerabilities, not to mention race conditions, memory leaks et al, running as local administrator to the internet? Let me think about it. NO!
Writing a web server is hard and re-inventing the wheel is simply unnecessary. This goes for more than just web servers, encryption, authentication (another recent doozy) and authorisation schemes among others have already been built for you. If you are homebrewing something like this you are doing it wrong.
I am constantly amazed at the lengths developers will go to to guarantee the insecurity of the application thy are writing. The application I am evaluating at work at the moment is a web application that, up until this version, has run atop IIS. Now in all their wisdom the manufacturer has decided it would be a far better idea to write their own web server. But wait it gets better the services for this particular application need to run with local admin rights including the web server. Wait, let me get this straight you want me to expose a custom written web server with who knows how many buffer, stack and heap overflow vulnerabilities, not to mention race conditions, memory leaks et al, running as local administrator to the internet? Let me think about it. NO!
Writing a web server is hard and re-inventing the wheel is simply unnecessary. This goes for more than just web servers, encryption, authentication (another recent doozy) and authorisation schemes among others have already been built for you. If you are homebrewing something like this you are doing it wrong.
Monday, September 28, 2009
The Register is reporting about a recent suicide bomber attempt on a Saudi Prince where the would-be assassin apparently concealed an explosive device in his *ahem* rear-end, which he then detonated upon meeting the Prince, resulting in more mess than injury (to the Prince anyway!)
I can remember flying out of Sydney not long after the infamous 'Shoe bomber' had been caught trying to destroy an airliner mid-flight. This was not long after the September 11 attacks and the already heightened airport security in place went into a new gear with the revelation that the humble shoe could be a new weapon.
I was pulled aside while going through a security check and asked to remove my shoes, which were then prodded, poked and flexed by a stern looking security guard before they were returned. No real inconvenience.
After reading the Register's article, I did give out a sigh of relief that Richard Reid hadn't tried to blow up that plane with explosives hidden elsewhere, otherwise those airport security checks could be even more painful!
What does the above have to do with information security? Not much, aside from raising awareness of the lengths to which people will go to accomplish their goals. For insiders intent on stealing data, even the most stringent security checks that may include inspecting laptops, cameras, thumbdrives and ipods would more than likely fail to find storage hidden in a pen, sunglasses, jewelry or coins.
I can remember flying out of Sydney not long after the infamous 'Shoe bomber' had been caught trying to destroy an airliner mid-flight. This was not long after the September 11 attacks and the already heightened airport security in place went into a new gear with the revelation that the humble shoe could be a new weapon.
I was pulled aside while going through a security check and asked to remove my shoes, which were then prodded, poked and flexed by a stern looking security guard before they were returned. No real inconvenience.
After reading the Register's article, I did give out a sigh of relief that Richard Reid hadn't tried to blow up that plane with explosives hidden elsewhere, otherwise those airport security checks could be even more painful!
What does the above have to do with information security? Not much, aside from raising awareness of the lengths to which people will go to accomplish their goals. For insiders intent on stealing data, even the most stringent security checks that may include inspecting laptops, cameras, thumbdrives and ipods would more than likely fail to find storage hidden in a pen, sunglasses, jewelry or coins.
Wednesday, September 23, 2009
A recent discussion about the security of an application generated the response "But this was OK'd by Legal so no more needs to be done".
Legal ≠ Secure. When a Legal department is asked for input, they are purely concerned with determining whether whatever is being presented to them contravenes the law. Most of the time the law will state something along the lines of "due care must be taken not to disclose data" rather than "you must use a minimum of 128-bit encryption to encrypt the data and the transmission".
What is due care? Well that's up to the judge to decide after the lawsuit has begun. Lawyers aren't normally Information Security professionals (well none I know!) and in fact often suffer from the same mideset as most non-IT professionals in that they tend to lump all things IT into the same basket*. As far as they're concerned, if someone in IT said we've done our best to secure something, they'll assume we've done due diligence and sign off, not really making the distinction of whether the 'IT guy' (or gal!) is technical or non-technical, a programmer, sysadmin or IT security expert. It may only be later during the court case when a prosecuting expert testifies that using DES to encrypt those passwords wasn't a good idea.**
When an IT Security Professional is asked for input, they generally have a pretty good grasp of legal requirements (well the good ones will!) and can always see legal for clarification. They are the ones who can ensure from a technology standpoint that the company is obeying the letter and the spirit of the law.
You wouldn't ask an IT Professional to to organize your legal defence, so don't ask a lawyer to vet the security of your applications. While the lawyers have their part to play, in ensuring that the law is being upheld, Legal ≠ Secure.
*In fairness to lawyers, I probably lump them all into the same basket too, not really paying attention to the difference between a patent lawyer and an ambulance chaser.
**If you're a lawyer reading this and don't understand this comment, go ask a friendly IT Security Professional!
Legal ≠ Secure. When a Legal department is asked for input, they are purely concerned with determining whether whatever is being presented to them contravenes the law. Most of the time the law will state something along the lines of "due care must be taken not to disclose data" rather than "you must use a minimum of 128-bit encryption to encrypt the data and the transmission".
What is due care? Well that's up to the judge to decide after the lawsuit has begun. Lawyers aren't normally Information Security professionals (well none I know!) and in fact often suffer from the same mideset as most non-IT professionals in that they tend to lump all things IT into the same basket*. As far as they're concerned, if someone in IT said we've done our best to secure something, they'll assume we've done due diligence and sign off, not really making the distinction of whether the 'IT guy' (or gal!) is technical or non-technical, a programmer, sysadmin or IT security expert. It may only be later during the court case when a prosecuting expert testifies that using DES to encrypt those passwords wasn't a good idea.**
When an IT Security Professional is asked for input, they generally have a pretty good grasp of legal requirements (well the good ones will!) and can always see legal for clarification. They are the ones who can ensure from a technology standpoint that the company is obeying the letter and the spirit of the law.
You wouldn't ask an IT Professional to to organize your legal defence, so don't ask a lawyer to vet the security of your applications. While the lawyers have their part to play, in ensuring that the law is being upheld, Legal ≠ Secure.
*In fairness to lawyers, I probably lump them all into the same basket too, not really paying attention to the difference between a patent lawyer and an ambulance chaser.
**If you're a lawyer reading this and don't understand this comment, go ask a friendly IT Security Professional!
Monday, September 7, 2009
APRA have released a discussion paper and draft best practice guide on the management of IT security risks.
APRA are the Australian financial services industry regulatory body. They oversee banks, credit unions, building societies, insurance and superannuation companies.
While light on specific detail, as a quick guide on what is expected for organizations under APRA's juristiction. It's a neat, concise set of guidelines that's not too jargon heavy - ie: good for Management to give them an overview of what is considered best practice (or 'prudential practice' as APRA call it).
I quite like the recommendation that organizations need to have "an overarching IT security risk management framework, addressing matters including an IT security strategy and a hierarchy of policies, standards, guidelines & procedures; and clearly-defined security principles for this strategy, addressing issues such as defence-in-depth, control diversity, breach detection and denial of unnecessary permissions/protocols."
It's good to see a body such as APRA publishing a document like this, I think it really helps raise awareness about some of these issues that may be lagging here in Australia compared to other parts of the world. My only criticism it that it's only a 'prudential guide' and non-enforcable, but that hopefully may change in the future.
The papers are available here.
APRA are the Australian financial services industry regulatory body. They oversee banks, credit unions, building societies, insurance and superannuation companies.
While light on specific detail, as a quick guide on what is expected for organizations under APRA's juristiction. It's a neat, concise set of guidelines that's not too jargon heavy - ie: good for Management to give them an overview of what is considered best practice (or 'prudential practice' as APRA call it).
I quite like the recommendation that organizations need to have "an overarching IT security risk management framework, addressing matters including an IT security strategy and a hierarchy of policies, standards, guidelines & procedures; and clearly-defined security principles for this strategy, addressing issues such as defence-in-depth, control diversity, breach detection and denial of unnecessary permissions/protocols."
It's good to see a body such as APRA publishing a document like this, I think it really helps raise awareness about some of these issues that may be lagging here in Australia compared to other parts of the world. My only criticism it that it's only a 'prudential guide' and non-enforcable, but that hopefully may change in the future.
The papers are available here.
Thursday, September 3, 2009
Subscribe to:
Posts (Atom)
Posts
