If you are an IT pro, more than likely you end up supporting many of your relatives and friends PCs and networks. I have my stable of software that I like to use to protect them. I can't just move them to Ubuntu. That's just not realistic right now. So I install Adaware from Lavasoft, Spybot Search and Destroy from safer-networking.org, Rootkit revealer, and Microsoft Defender. After installing these and running all the scans I patch their OS and their IE. I download the latest version of Firefox. Then I make a restore point and back up their data directories to my USB drive.
Then I sit with them and discuss a bit about what they do with their PC. I'll surf a bit with them watching so that I can show them the different types of messages that they will get during a browser session. I will show them the dialogs and explain some of the different ways that attacks can come. I discuss the potential for them to move up to the paid version of the above software. This allows them to get some of the extra features that might help automate the protection of their PC.
Then if they have been compromised I will discuss with them how to use the free credit report from the three credit reporting agencys to monitor their credit. Most people think that you only get one credit report per year. The law states that you get 1 per year from 'each' reporting agency. This means that you can pull a credit report 3 times per year. The other thing I have them look into is freezing their credit. This is available in most states. A person can place a lock on their credit and the agencies will deny any attempts to get credit in that name. This of course can be removed by the person if they need to apply for some credit. There is usually a charge to do this.
Here is a great website that usually has the latest info on breaches of security http://datalossdb.org/
If there are any other suggestions or techniques that can help manage identity risk please feel free to comment.
Sunday, February 22, 2009
Friday, February 20, 2009
Cheap and painless backup
My wife currently does the books for two small businesses. Each one has critical data files that if lost would severely hinder sending invoices out. The applications we are talking about here are Quicken and Quick Books. After having a near miss on losing a quarter's data, she tasked me with coming up with a solution. The solution I cam up with was the Corsair Flash Survivor. This flash drive is contained in a milled CNC aluminum capsule. It has O-rings to seal out moisture. I could drive over it with my car and I wouldn't be able to crush it. It comes in 4, 8, 16, and 32 GB sizes.
I purchased two 4GB models from NewEgg for $10 ea. She backups the files to one device, and then each quarter swaps it with the one stored at the other business owner's house. The Intuit products are really nice in that they prompt her to backup every time the application closes the file.
For more details check out the Corsair site
I purchased two 4GB models from NewEgg for $10 ea. She backups the files to one device, and then each quarter swaps it with the one stored at the other business owner's house. The Intuit products are really nice in that they prompt her to backup every time the application closes the file.
For more details check out the Corsair site
Wednesday, February 18, 2009
Wrong Answer... Would you like to try again?
Recently at work we did our change to the next years Insurance plan. I went to the company's website to register and login. I attempted to register with my id in lower case. When I tried to register I found that I was already registered. Well and good. Let's login. So I go back to the login screen and enter my ID in lowercase and my suspected password... Crash. Server returns with a 500 error and stack trace for a null pointer error. I can tell they are using Websphere etc. Not the sort of error you want your users to see or any black hat types either.
Well I attempt to find the number to call on this. I talked to my HR rep and we found the 800 #, can you guess where? She logged on and found it (wait for it) Yes on the inside of the website. Wouldn't it be better listed outside where people could find it?
Anyway I called the number and got the technical support person. I gave the require info and I expalined what my problem was. She found that I needed to login in ALL CAPS. So let me get this right... login in lower case = NPE, login in upper case = SUCCESS. What has me scratching my head is that my registration attempt was in lower case and it was able to successfully figure out that I was already registered. So on some parts of the site your login is case specific and some parts it's not. This must be a new security technique that I did not know about.
The sad thing is the advice from the technical dept was I would just have to make a note to use upper case in the future. She wasn't at all intersted in making a ticket to get it FIXED! She also offered no option to reset my id to lower case.
Well I attempt to find the number to call on this. I talked to my HR rep and we found the 800 #, can you guess where? She logged on and found it (wait for it) Yes on the inside of the website. Wouldn't it be better listed outside where people could find it?
Anyway I called the number and got the technical support person. I gave the require info and I expalined what my problem was. She found that I needed to login in ALL CAPS. So let me get this right... login in lower case = NPE, login in upper case = SUCCESS. What has me scratching my head is that my registration attempt was in lower case and it was able to successfully figure out that I was already registered. So on some parts of the site your login is case specific and some parts it's not. This must be a new security technique that I did not know about.
The sad thing is the advice from the technical dept was I would just have to make a note to use upper case in the future. She wasn't at all intersted in making a ticket to get it FIXED! She also offered no option to reset my id to lower case.
Friday, February 6, 2009
Creeping elegance
In the life cycle of an enterprise application there are many stages. In my experience, most applications start with simplified requirements and then the go though iterative stages where the actual set of requirements get enunciated and the application gets extended. Compare that with new requirements that get added because the customer sees the possibilities of the application and says "if we can do X then how much more would it be to get functionality Y?".
here is a listing of the stages of a software application that I have seen.
Stage 1 simplified requirements. (I wish for)
Stage 2 revised requirements (iterate) (but what about this...and that. More of the same)
Stage 3 new requirements (iterate) (if you can do that then you should be able to do this)
Stage 4 stabilization (removal of the rough edges)
Stage 5 automation (we've got to live with it. let's make it work for us)
Stage 6 migration (we need to move to new hardware, or software)
Stage 7 consolidation (can your application live on the same hardware as?)
Stage 8 maintenance (care and feeding)
Stage 9 end of life (my only friend the end)
Don't get confused here. I'm not putting forth my idea for a new SDLC. The SDLC is an attempt to manipulate these stages, to eliminate their eccentricity. I'm simply listing the stages that an enterprise application goes through. This is from personal experience in my 13 year career.
I love to have projects where Stage 1 and 2 combine. Basically all requirements get exposed up front. I may have actually had a project like that once. I don't think we can ever get the requirements fully enunciated for many reasons. Off the top of my head, the first is the customer really does not know how to define that problem that they want to solve. Your communication skills (mostly listening) will serve you well here. The second is that your customer really does not know what you can do. It's good to go into a requirements meeting knowing the techniques you have mastered and be able to present combinations of these techniques as solutions to the problems that the customer has. Another biggie is principal stakeholders that can't make the requirements meetings, or due to politics cannot fully tell you the complete requirements. Sometimes they just don't know how to say it where you can understand it. This can be a real pain. I like to use a technique that doctors use when diagnosing patients. I will ask the same question many times in different ways. The differences in the answers can lead you to exposing a subtlety in a requirement that may be overlooked.
The other interesting twist to stage 1 and 2 is when you have a previous application that you are duplicating. This gives you a big leap in terms of understanding some of the requirements but only if the users will give you input on what needs to stay and what needs to go. Sometime the users are hostile because they are enternched in the old system and don't want to change.
I like use the term "Creeping Elegance" to describe the stages 3-5. The application is several iterations away from the original plan due to the discovery of the new requirements. How you integrate this new functionality can determine whether or not you end up with a shiny turd or an application that can be extendable. Remember design generically, and refactor often. If a data relationship exists in a 1-1 fashion, investigate the 1-many. Don't just solve for the simplest case. Understand the effects on your software if you are required to handle more than just one instance. Also understand the systems you might be sharing data and files with. For example, many systems have conflicting limitations on file names. If your system uses a Windows/Unix type filename you are in for a rude awakening when those files need to be sent and processed on a mainframe.
The causes of Stages 6 and 7, could be a company take over, changing vendors for software or hardware, net effect is that a move of your stabilized system is coming your way. Just when you thought every thing was all locked down, they decided to move the data center to Boise. This raises new challenges in continuity (how do we continue to run as we transition the app), as well as recertifying the entire platform.
Stage 8 maintenance is usually the domain of the new guy, usually so he can get an idea how the system works. He needs to be watched closely to insure that what he implements is generic and will not interfere with extensibility of the application.
The end of the road for some applictions, means a transition to a new technology. The hardware may come and go but software can live forever. Perhaps the app is just being dropped. Perhaps a rewrite will occur. If this happens take the opportunity to assess the application. Understanding the rough edges and how they came to be can help you make a better product in the future.
here is a listing of the stages of a software application that I have seen.
Stage 1 simplified requirements. (I wish for)
Stage 2 revised requirements (iterate) (but what about this...and that. More of the same)
Stage 3 new requirements (iterate) (if you can do that then you should be able to do this)
Stage 4 stabilization (removal of the rough edges)
Stage 5 automation (we've got to live with it. let's make it work for us)
Stage 6 migration (we need to move to new hardware, or software)
Stage 7 consolidation (can your application live on the same hardware as?)
Stage 8 maintenance (care and feeding)
Stage 9 end of life (my only friend the end)
Don't get confused here. I'm not putting forth my idea for a new SDLC. The SDLC is an attempt to manipulate these stages, to eliminate their eccentricity. I'm simply listing the stages that an enterprise application goes through. This is from personal experience in my 13 year career.
I love to have projects where Stage 1 and 2 combine. Basically all requirements get exposed up front. I may have actually had a project like that once. I don't think we can ever get the requirements fully enunciated for many reasons. Off the top of my head, the first is the customer really does not know how to define that problem that they want to solve. Your communication skills (mostly listening) will serve you well here. The second is that your customer really does not know what you can do. It's good to go into a requirements meeting knowing the techniques you have mastered and be able to present combinations of these techniques as solutions to the problems that the customer has. Another biggie is principal stakeholders that can't make the requirements meetings, or due to politics cannot fully tell you the complete requirements. Sometimes they just don't know how to say it where you can understand it. This can be a real pain. I like to use a technique that doctors use when diagnosing patients. I will ask the same question many times in different ways. The differences in the answers can lead you to exposing a subtlety in a requirement that may be overlooked.
The other interesting twist to stage 1 and 2 is when you have a previous application that you are duplicating. This gives you a big leap in terms of understanding some of the requirements but only if the users will give you input on what needs to stay and what needs to go. Sometime the users are hostile because they are enternched in the old system and don't want to change.
I like use the term "Creeping Elegance" to describe the stages 3-5. The application is several iterations away from the original plan due to the discovery of the new requirements. How you integrate this new functionality can determine whether or not you end up with a shiny turd or an application that can be extendable. Remember design generically, and refactor often. If a data relationship exists in a 1-1 fashion, investigate the 1-many. Don't just solve for the simplest case. Understand the effects on your software if you are required to handle more than just one instance. Also understand the systems you might be sharing data and files with. For example, many systems have conflicting limitations on file names. If your system uses a Windows/Unix type filename you are in for a rude awakening when those files need to be sent and processed on a mainframe.
The causes of Stages 6 and 7, could be a company take over, changing vendors for software or hardware, net effect is that a move of your stabilized system is coming your way. Just when you thought every thing was all locked down, they decided to move the data center to Boise. This raises new challenges in continuity (how do we continue to run as we transition the app), as well as recertifying the entire platform.
Stage 8 maintenance is usually the domain of the new guy, usually so he can get an idea how the system works. He needs to be watched closely to insure that what he implements is generic and will not interfere with extensibility of the application.
The end of the road for some applictions, means a transition to a new technology. The hardware may come and go but software can live forever. Perhaps the app is just being dropped. Perhaps a rewrite will occur. If this happens take the opportunity to assess the application. Understanding the rough edges and how they came to be can help you make a better product in the future.
Subscribe to:
Posts (Atom)
