Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security Books Media Book Reviews

The Pragmatic CSO 100

Ben Rothke writes "The Pragmatic CSO: 12 Steps to become a Pragmatic CSO is worth reading for one sentence on page 12 which states: It's not about technology — it's about business. The even better news is that the book is full of insightful ideas like that, on how information should work, and how to make it work in today's large enterprise organizations. One of the mistakes many security professionals make is that they think of security for its own sake, when security is simply meant to support the business. CxO's could care less about encryption key lengths and operating systems. While they don't care about the technical details, the people from information security often mistakenly communicate to them in those terms." Keep reading for the rest of Ben's review.
The Pragmatic CSO: 12 Steps to become a Pragmatic CSO
author Mike Rothman
pages 235
publisher Security Incite
rating 9
reviewer Ben Rothke
ISBN None - self published
summary Pragmatic, insightful and valuable looking into making security work
The book notes that there are three main causes to the poor state that information security finds itself in today in far too many organizations: Security is viewed as a technical function - Security staff are often part of the technical teams, but not members of the management team. The bad guys are getting better - In years past, attackers would get your attention by playing music in the background as their virus infected your workstation. Today's attacks are built around stealth techniques. Attackers do their best to hide from your IDS, and often easily do so. Auditors are tougher- Both internal and external auditors are finally getting the power they deserve. The days of having them rubber stamp the audit are slowly coming to a close. The Pragmatic CSO:12 Steps to become a Pragmatic CSO details a 12-step program, which is a structured program on which to build a strong information security program. The book goes through those steps as a way to keep you, as the CSO, focused on the goal. That goal is to demonstrate the value of information security management and the level of security to the internal and external auditors.

The books 4 sections and 12 steps are structured similarly, beginning with what you will learn in the specific step, a dialogue-based introduction akin to an AA (Alcoholics Anonymous) session, and an action plan for each step. Personally, I found the AA dialogues a bit cheesy, and by step 6, found them a bit annoying. Aside from that issue, the book is a highly valuable guide in which a new CSO can use to directly assist them in their job. A new CSO is recommended to use the guide in their first 100 days in office. Such an approach can spell the difference between success and failure.

As its title implies, the book is all bout being pragmatic. This practical approach is needed, as step 2 notes that it is hard for many security professionals to get beyond the typical vulnerability-centric definition of success. It is not about how many vulnerabilities are found, rather the pragmatic way in which their are handled.

Part of this pragmatic approach is being realistic of the state of security in your origination. Step 7 underscores this when it shows how a CSO should never underestimate to things : the ability of the bad guys to make you look bad, and the ability of users to do something really stupid. The preceding is just one example of many where the book shows the reader what security is like in the real-world, as opposed to the often described pristine cryptographic world of security when Alice and Bob are involved.

Perhaps the most important point the book makes is that pragmatic CSO's have no religion when it comes to security and technology, besides doing the right thing for their business and protecting their assets. Far too many people in security and technology turn technology choices into religious wars, most of which center around Windows, Linux, Cisco and Juniper.

Step 11 details metrics and benchmarks and has a number of constructive questions in which to benchmark against. The areas of questions include effectiveness, awareness, attitude and financial. This is needed as metrics and benchmarking are needed to measure how you and your security team are doing, and to identify areas in need of improvement. Benchmarking can also point out areas which your organization differs from the norm. While that is not necessarily a bad thing, it is necessary to know when to follow so-called best practices, or whether to do what is specifically right for your organization.

The Pragmatic CSO:12 Steps to become a Pragmatic CSO is a most valuable book in that it provides fresh, real-world advice, as opposed to generics rehashed best practices. Author Mike Rothman's premise is that today's CSO's need to act more like business people in order to thrive. With firms laying-off back-office technology staff by the thousands, having this front-office approach is not only timely, it may just save your job.

Ben Rothke is the author of Computer Security: 20 Things Every Employee Should Know.

Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

The Pragmatic CSO

Comments Filter:
  • by msauve ( 701917 ) on Monday July 28, 2008 @10:11AM (#24368217)
    Spock or T'Pol?

    CSO means "Chief Science Officer," right? Because the article doesn't bother to define it.
    • CSO [wikipedia.org]

      I would opt for Combined Sewer Overflow [wikipedia.org] , but it's Chief security officer [wikipedia.org].

      • I would opt for Combined Sewer Overflow [wikipedia.org] , but it's Chief security officer [wikipedia.org].

        "Captain! We are being hailed!"
        "On screen, Mr. Worf."

      • My first thought was "Chicago Symphony Orchestra."
    • There should be a karma modification if they post an article with a specialized acronym and don't define it they should loose points. CEO, CIO are common enough but CSO, CTO...
      I first though they were talking about the Chief Software Officer.

      • >>>specialized acronym

        since when is CSO a 'specialized acronym'??

        if you read any tech guide, its presumed that all knows what CSO/CISO stands for.

        • CSO is relatively new though. It use to be the domain of the CIO. And sure we all know what CISO is, they make routers and such :-).

          • and that is the problem!!!

            most cio's are completely clueless when it comes to security.

            A CIO answers a security issue like this:

            80% of the time: my sysadmin can do that
            19% of the time: my firewall admin can do that
            1% of the time: and this is the answer of the small minority of smart CIO'S: I will have my security engineering team do that.

          • by morcego ( 260031 )

            The position of CSO is stated and defined on the ISO 17799 document, which is anything but new.
            For anyone working information security not to have read that document ... well, I don't think it is worth commenting. (Even if you read, but don't agree with it)

      • Re: (Score:3, Insightful)

        by fm6 ( 162816 )

        Somehow I keep thinking "Crime Scene Optimization".

        Here's why posting a bad article shouldn't affect your karma. Karma and moderation is Slashdot's way of giving good posts more visibility than bad ones. (It doesn't work that way currently, but that's the idea.) For articles, that same function is provided by the editors. Articles like this get posted because because the editors are sloppy. The accept stories where the language is unclear, where the story misrepresents (or even flatly contradicts) TFA, or w

    • spock was logical, NOT pragmatic!
    • CxO is a designation and a functional description. Many organizations choose not to designate a person as such, but still has some person or persons who perform the functions. In some states and countries, as well as for certain designations, the designee assumes certain legal responsibilities and can be held accountable as an [Official] representative of the organization, irrespective of any title the designee may hold. For example, in many orgs, the [senior] vp of finance is also the CFO, but in some the
    • What, Worf and Tuvok aren't in the running?

      It's because they're black, right? You leave Star Trek out of your racist agenda.

      • Oh, so Tasha Yar was just alien food? I notice the blonde-haired white woman doesn't get a mention, since we're being all prejudicial. Hypocrisy, thy name is Trekkie.
    • by fm6 ( 162816 )

      T'Pol is sexier.

      No wait, I'm speaking as a straight male. I seem to recall that back in the 60s many women considered Spock the sexiest character on TV. It was all that torment caused by his inner human-vulcan conflict.

      Anyway, they're equally pragmatic. You have to deal with facts. To do otherwise would Not Be Logical(tm).

  • Security (Score:2, Insightful)

    by Wiarumas ( 919682 )
    Security is vital knowledge... as time passes, the criminals get smarter. It is impossible to mitigate all possible threats 100% of the time, but in order to keep the probability of these threats low, you have to be on the same playing field as the criminals. If not, well, you've seen what happened to the Death Star.
    • by MR.Mic ( 937158 )
      Oh crap, you're right! I don't want my office building to explode due to an open exhaust port! I better get on the roof and start duct taping over those air conditioning units today!
  • ack (Score:4, Funny)

    by Trailer Trash ( 60756 ) on Monday July 28, 2008 @10:16AM (#24368327) Homepage
    I read the headline as "the pragmatic SCO", and was thinking "where?"
  • The only link relevant to the new book in TFS demands my email address in order to see anything. Not terribly motivating.
    Besides, 12 steps? I'm recovering from that, thanks.
    • The only link relevant to the new book in TFS demands my email address in order to see anything.

      Correction, the page just requires scrolling down to see the 12 steps. Damn, foiled by my own pessimism! But at nearly $100 for a download, couldn't you at least buy an ISBN?

      • Especially because there's only one real noteworthy step:

        Step 9: Train the Users

        Users are the weakest link in the security chain, so all the technology in the world will not help if a user gives up a password to the bad guys. In Step 9, you learn why a structured user awareness training process is critical to educate users to think and act securely and avoid many of the easy attacks used every day.

        I think that's being a little easy on the users, though ;)

    • speaking of people who use acronyms w/o (without) defining them...

      what is TFS?

  • by zappepcs ( 820751 ) on Monday July 28, 2008 @10:19AM (#24368375) Journal

    FTFS:

    Step 7 underscores this when it shows how a CSO should never underestimate to things : the ability of the bad guys to make you look bad, and the ability of users to do something really stupid.

    Emphasis is mine. Speaking of things that make you look stupid? Irony?

    Seriously, this advice works for anything.

    • It is not about how many vulnerabilities are found, rather the pragmatic way in which their are handled.

      Yeah. It's hard to be taken seriously when you make stupid grammatical errors. Your typical /. post is one thing but a book review is another.

      Hopefully, this guy had a good editor for his own book. They're invaluable.

      Cheers,
      Dave

    • Sounds like someone used M$ Wurd with the autokorrect feature a bit too much.

  • by pzs ( 857406 ) on Monday July 28, 2008 @10:19AM (#24368389)

    This idea of people focussing on their own job role to the detriment of the overall organisation is very common.

    Finance people think hours filling in expenses claims over £30 lunches, support who won't let you install a vital and harmless piece of software because it's against regulations, managers who call so many status report meetings it's impossible to get any real work done... this kind of stuff happens all the time.

    A lot of people are self important, narrow minded and don't see the big picture. In other news, water is wet.

    • by Notquitecajun ( 1073646 ) on Monday July 28, 2008 @10:47AM (#24368875)
      The worst part is when it's your JOB to perform said role, and you get in trouble for both not doing it AND doing it. Security jobs are a catch-22 - you can get blamed when things go wrong, but when you try to do your job, it can be seen as getting in the way.
      • by pzs ( 857406 )

        In a previous University job, I was responsible for a server that got hacked. It was entirely my fault for installing services carelessly but even so, they were really good about it. Instead of bollocking me or cutting off my privileges, they told me exactly what to do to clean the machine along with some really useful documentation to prevent it from happening again.

        Their attitude seemed to that at a University, you need flexibility to get stuff done so bad things are bound to happen occasionally. This out

      • Where I work Security is tied closely to Internal Audit so naturally we are hated, but it gives us leverage to get our job done. We are viewed as getting in the way but my boss gives people a BARF (Business Acceptance of Risk Form)any time they give us lip "we've always done it this way." They always back down because its their ass now
    • Re: (Score:2, Insightful)

      by silanea ( 1241518 )

      [...] support who won't let you install a vital and harmless piece of software because it's against regulations [...]

      Has it never occured to you that they might simply be protecting their jobs? Someone put those regulations in place, and IT/tech support are required to make sure those regulations are followed. If some lowly grunt at helpdesk allows you to install a "vital and harmless[1] piece of software" and anything goes wrong, it's not so much your ass on the line as theirs. So next time think twice before laying blame.

      Find out who's responsible for IT regulations and make your case to them for the permission of your

    • Finance people think hours filling in expenses claims over £30 lunches

      If it takes you hours to do this, you're doing it wrong.

      Furthermore, which only adds to your point, there are reasons that controls on those claims exist that you might not be aware of. Sure, it seems like a waste of time to you, but have you considered the potential cost to the company for not complying with regulations requiring that documentation?

      There is potential liability when claims are not reported properly, or when

      • Always include time spent filling in timesheets on your timesheets.

        It may seem recursive but its important that its included... if the timesheeting or accounting system is so bone-headed that it takes hours to complete then this should be accounted for.

  • by Anonymous Coward on Monday July 28, 2008 @10:37AM (#24368727)

    I tried discussing security "pragmatically" with our PCI level 1 auditor, and it didn't go well.

    He wanted to see an example of all 200+ recommendations, even if it made no sense for our environment.

    So yes, don't be arbitrary if you get to make up the rules. But as long as there are large fines assessed by auditors who cling to arbitrary rules than arbitrary security rules are here to stay.

  • by pla ( 258480 ) on Monday July 28, 2008 @10:41AM (#24368791) Journal
    It's not about technology -- it's about business.

    No.

    The entire IT world currently exists for its own sake. The business world has discovered they can use it, to some extent, but let's not take that too far in ascribing a raison d'etre to all things tech.

    We have computers because geeks like toys. In order to afford more toys, we whore ourselves out to the business world... But the relationship ends there. If we can help our employers make more shiny colorful reports measuring how much money we waste on blue vs green widget paint, great, good for them (and the landfills). If not... I can't speak for everyone on Slashdot, but at the end of the day, I go home and do my best not to think about work.

    Yet, I still go home, fire up my PC, and continue improving the very skills that make me valuable to my employer (I'll skip the obvious gaming and porn jokes here). I, as I believe of most geeks, do it for its own sake, because I love technology and toys - Not because I have some BS "compelling business case" to dedicate much of my life to technology for the gain of CEOs who wouldn't give me the time of day to spit on me if they came across me dying in the desert.
    • by tb()ne ( 625102 )

      I have not read the book but I don't think the "it" in the quote refers to your reasons for you performing your job. It refers to the reason your job exists.

      • by orasio ( 188021 )

        The GP raises an interesting point. He says that IT jobs are superfluous, and only exist due to the easiness of selling tech stuff to CxO's.
        Everything else gets built to support and improve installed IT systems.
        While I don't think it's exactly like that, I think it's an insightful point.

    • by CowTipperGore ( 1081903 ) on Monday July 28, 2008 @11:25AM (#24369565)

      The entire IT world currently exists for its own sake.

      First, the argument is made in the context of the business world, not about what you do with your free time. Further, your whole comment reflects the conflicts in attitudes that the book is attempting to address. Too many individuals are unable to think outside of their silo, seeing themselves and their work as inherently important without considering the business goals and how they impact them. I've seen attitudes like yours ruin IT departments (and research departments, and facility service departments, and accounting departments, etc) as the department becomes a fiefdom concerned more with protecting and growing its kingdom. In most businesses, IT and all other ancillary departments, exist only to facilitate the primary business processes of the company.

      I recently watched a large electric utility outsource their IT functions to EDS. This decision was made primarily because their IT structure was out of control and no one knew how to check it. Everyone in IT was transferred to EDS or they left the company altogether. In the two years since, EDS has trimmed the their staffing on the contract by at least 50%. My prediction is that in another year or two, the company will bring IT services back in house again and will do it with staffing about 25% of what it was before they outsourced. As an IT manager, I make sure that this isn't a good option for our department by communicating regularly with upper management, by always tying our work to company goals, by maintaining quality support, and by never allowing the department to become obviously overstaffed. IT employees who can't tie their toys to our goals do not survive in this culture.

    • by homer_s ( 799572 )
      We have computers because geeks like toys. In order to afford more toys, we whore ourselves out to the business world.

      Most of the IT world is a bit more mature than you seem to be.
  • by xrayspx ( 13127 ) on Monday July 28, 2008 @10:46AM (#24368851) Homepage
    That's a tough thing for security professionals to draw a distinction with. Everything a company does should weigh the business value of a proposed technology vs the risk of what happens if that technology breaks. So if you have an old firewall or licensing restrictions that won't let you use 3DES or AES for your VPN, and are stuck with DES, the company (CSO) should be weighing the cost of upgrading vs the risk of loss to the company if your DES VPN is broken.

    If you have credit data passing across, there may very well be PCI/DSS issues and fines, but if the VPN is just there to pass pictures of kittens from one site to another, you might not care and may not need 3DES or better.

    Many security professionals see this as sub-optimal, and will bitch. However as long as the senior management is aware of the risk and has decided it's a risk worth taking, then you've done your job as a security person.
    • Do please explain how you quantify the probability of your single-DES VPN being compromised. I'm all ears. ("Well, none of us are perfect, D.M.!")
      • Re: (Score:3, Interesting)

        That's the problem. Return On Investment asks you to arrive at a figure by multiplying a bunch of numbers YOU DON'T KNOW TO START WITH:

        "Most textbooks will tell you to compute the expected return on investment, by working out the annual cost of not doing X ( annual probability of occurrence times average loss if something bad happens ) minus the cost of not doing X. If you save money by implementing a safeguard, do it.

        The problem is that you don't know any of these numbers very well at all, but you're p

        • Exactly!

          my guess is that there are maybe 5 security pros in the US who know how to deal with ROSI.

          All others make up their own data as they go along.

        • Quite so. What peeves me (as a practioner in the field) is the people who try to decide where to spend their security dollars by doing absurd calculations using such unmeasurable values. (not to mention all the certs that require you to parrot such nonsense as if you believed it.) "...you're pretty sure that... " comes down to gut feel, experience, and professional judgement. This is bad news for the attempts to put infosec on a similar professional basis to business functions like audit or accountancy (o
      • by xrayspx ( 13127 )
        It's not about the probability of someone breaching 56-bit DES, it's about the consequences.

        How about Hannaford [scmagazineus.com] or TJX [scmagazineus.com] using weak keys? Their CSO should be weighing the cost of changing their infrastructure to not use wireless, or using strong keys, MAC Filtering and firewalls to mitigate their exposure vs the risk of losing 47,000,000 credit and debit card numbers.

        The CSOs of those companies would need to weigh different factors than businesses with no B&M retail outlets. It's about deciding "H
        • by Firehed ( 942385 )

          That's a very interesting viewpoint, but how much actually came out of the Hannaford debacle? A whole lot of bad press for a week or so, and then nothing at all. I, for one, have not changed my shopping habits, nor have any of my family - and they tend to shop at Hannaford more often than I do. Of course this anecdotal evidence can only go so far (which is to say, not far at all), but all things considered I'd suggest that losing some ungodly amount of financial information was actually the cheaper optio

          • by xrayspx ( 13127 )
            From a PCI DSS compliance standpoint, the fines for being a non-compliant tier 1 were pretty strict. Hannaford stated that it was fully PCI compliant. From what little I know of Hannaford's actual operation, it's hard to say, but I would think they should have had to answer "no" to a few more checkbox items.

            The problem is that credit card processing companies will threaten non-compliant retailers with shutting down their authorization until they achieve compliance, or are making provable headway. So H
  • by dpbsmith ( 263124 ) on Monday July 28, 2008 @10:52AM (#24368961) Homepage

    Business-side executives who think they can manage without understanding anything at all about the technical details are just as arrogant and dangerous to the bottom line as techies who think they don't need to understand anything about the business.

    In a wonderful Dilbert cartoon, the PHB says "Reasoning that anything I don't understand must be easy..." and assigns Dilbert an impossible task predestined for failure.

    People on both the money side and the technical side need to work for mutual respect and understanding, and both need to be patient enough to listen to, and understand, material that doesn't fall within their specialty.

    • Executive management (except CIO/CSO obviously) shouldn't need to understand anything about the technical details. The technical groups should be doing the necessary analysis and giving them the necessary information to make choices about technology initiatives.

      The problems come when the execs ignore what their direct reports are telling them, or if the technical people aren't providing the execs the information they need to make the decisions. I don't think trying to educate the execs on the technical de

      • Executive management (except CIO/CSO obviously) shouldn't need to understand anything about the technical details. [...]

        I disagree. A CEO doesn't need to know how to code, but they need to have a grasp of what IT is. Their business - by now, just about any business regardless of its industry sector - depends to a varying degree on software. The larger this degree, the more important it is for the top brass to understand what IT consists of and how to manage it. Not in detail, mind you. But they ought to understand the basic principles and processes behind it. Just like they ought to have an understanding of economics, even t

        • by Bodrius ( 191265 )

          Their business also depends to a varying degree on accounting, human resources, legal departments, and janitorial services.

          For most businesses, all of the above have a longer history as indispensable resources - and for most businesses, any of the above is far more indispensable.

          Yet you wouldn't expect a CEO has to understand the technical details of the legal cases, recruitment processes, or cleaning supplies - *unless* that happens to be the core business of the company.

          Taking care of the technical detail

      • >>Executive management (except CIO/CSO obviously) shouldn't need to understand anything about the technical details. Bull!! Imagine saying the head of a hospital shouldn't need to understand anything about the technical details. We would not tolerate this in any other industry, why IT????
        • by Bodrius ( 191265 )

          That's a bad analogy for two reasons:

          - Most companies are not IT/Software companies - they have IT departments and CIO/CSOs as part of their corporate infrastructure.
          For most cases, that's like demanding from the hospital administrator an understanding of the details of the cafeteria food production.

          - That aside, health administrators may be a particularly bad example because they can be from a business background (so apparently we do tolerate it) - and because medicine leads to high degrees

          • ok, so its not a perfect analogy, that does not map perfectly.

            but.... in IT, there is way too far of a disconnect. you dont have such disconnect
            in other industries.

            • by Bodrius ( 191265 )

              Yes you do!

              *Unless* you work on a software / IT company, only then does this argument even apply.

              Most IT shops exist in corporations that have a different core business.

              Fundamentally, what the CEO needs to understand is the core business of the company - if that happens to be technology, then great, but if they're making widgets then his expertise and time spent better be on the industry and market of widgets - not on IT.

              I'd be most interested in some examples of this 'disconnect' you talk about - how it is

              • >>I'd be most interested in some examples of this 'disconnect' you talk about - how it is not tolerated in other industries.

                Read some issues of HBR. Articles where the connect is best between the tech and biz people, profits are also better. /jay

    • by wzzzzrd ( 886091 )
      Business-side executives who think they can manage without understanding anything at all about the technical details are just as arrogant and dangerous to the bottom line as techies who think they don't need to understand anything about the business.

      No, it is just fine for a business executive to don't understand any technical detail. However, it is not fine for a business executive to not trust people assigned to understand all the technical details and worry about them. That is arrogant. But to say "We
  • I read the title as "The Pragmatic SCO" and was about to write angry comments. Loud ones with torches and pitchforks. :P
  • A CSO is a combined sewer overflow. Where a sewer system is old, is was designed to carry both stormwater (rain fall off houses and streets) and sanitary sewage (from inside houses) to an outfall (and later to treatment plants). Modern systems have separated sewers, one for stormwater one for sanitary. Only the sanitary goes to the treatment plant. In the city where I live, the outer parts are modern, but the centuries-old infrastructure downtown is still served by combined sewers. Dry days, the sewage
    • Re: (Score:1, Funny)

      by Anonymous Coward

      They want to deliver vast amounts of sh!+ over the sewer. And again, the sewer is not something that you just dump something on. It's not a big truck. It's a series of tubes. And if you don't understand, those tubes can be filled and if they are filled, when you put your sh!+ in, it gets in line and it's going to be delayed by anyone that puts into that tube enormous amounts of stormwater, enormous amounts of sh!+.

  • As soon as security is reduces from the maximum (which is typically sensibkle to do if it has business advantages), techniological quastions like keylengths become very important. There is one large financial institution in Swizerland, that had to fear all ist banking cards being broken, because they had too short keys. So, it is important to have business and technolocical facts and understand both.

  • is that the term CSO wasn't defined anywhere. Apparently the reviewer was mistakenly communicating to use in security terms, which is one of the things IN THE REVIEW that he warns about.
  • by petes_PoV ( 912422 ) on Monday July 28, 2008 @11:40AM (#24369845)
    Well thanks for letting the cat out of the bag. If that's the best sentence in the book I think I'll pass.

    Everybody who's worked/working in business (as opposed to academia, where your success is really just the weight of papers you put out - right?) for any length of time and isn't still doing the job they started with knows this implicitly. None of IT is about anything except the business - it's merely a means to an end, or a necessary evil depending on how good your IT organisation is.

  • Was I the only one who thought this was an article about the Chicago Symphony Orchestra when seeing "CSO" in the headline?

  • CSO = Chief Security Officer
    CIO = Chief Information Officer
    CTO = Chief Technology Officer

    At the end of the day, these roles are defined by the business and only marginally the same from company to company. Security is usually part of a broader IT strategy (so no specific corporate officer, but an IT lead.)

    In any event, IT is almost always a service to business, and so top level organizational problems trickle down (as sometimes infrastructure politics bubble up.)

    Here is a fun rant, from the armchair cio [armchaircio.com].

  • A book for CSOs? (Score:1, Flamebait)

    by tuomoks ( 246421 )

    How you can be a CSO if you already don't know what this book describes? This book is more like wannabe CSO handbook.

    Now - I don't blame the book, it is good (IMHO), but it states facts that have been know 30+ years? Maybe forgotten? But for CxOs or even security managers - how the heck did they get their jobs if they don't already know this?

    That seems to be the problem today, the basics! For example security never was, isn't and never will be technology - it is a business fact, much bigger than IT, securin

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...