Re: CRIME Computers vulnerable at Oregon department

From: T. Kenji Sugahara (sugahara@private)
Date: Thu Sep 26 2002 - 16:48:00 PDT

  • Next message: Crispin Cowan: "Identity Theft (was: CRIME Computers vulnerable at Oregon department)"

    Sorry for the layout!  From all the posts, it seems like the following 
    are some common ideas:
    
    There needs to buy-in from the top down on security issues.
    RFP process needs to be improved.
    The state should get the source code for any custom built application.
    Open source is a viable option and should be explored further.
    There needs to be standards.  Centralization is another option, but 
    standards should take priority.
    The hiring process needs to be improved.
    
    Any other ideas?
    
    Jerry: "I do know the DAS IT folks talked about developing a lab to 
    work on such issues to then make recommendations to the various 
    agencies about security issues."
    
    Did anything come of it?  I also agree that it would be great to come 
    up with some sort of roundtable to really discuss concrete ideas.
    
    Dion:   "It would be his job to take a month or so, evaluate, talk to 
    managers and techs, find out what works and what doesn't, and after 
    gathering this information, come up with a plan and be free to run with 
    it."
    
    I do like the idea.  I was also thinking that it would be beneficial to 
    still have IT departments in each of the agencies to deal with the day 
    to day tech support etc.  As you probably know, it'd be much easier to 
    troubleshoot a computer when you are right in the room.  It is my 
    understanding that many of the techs are tied up dealing with the "my 
    computer doesn't work," problems and usually don't have time to keep up 
    on developments in the technology field unless they take it upon 
    themselves to do so.  I would propose have a central IT department that 
    would take care of standards and problems that require a higher degree 
    of skill.  e.g. special teams.  These folks would take care of issues 
    such as security, standardization, and across the board purchasing.  
    They would have the time to stay on top of industry developments 
    because they wouldn't be tied down with all the day to day tech support 
    issues.  (If this is unclear it's because my mind is a little flaky 
    today)
    
    Andrew: "Why do I or the customer need source code to do this? We can
    support the products as is and all is peachy. "
    
    True enough.  As said before, source code isn't required in all 
    applications.
    
    "Furthermore, the state does not need to entertain competitive bids to 
    get a fix. If they buy an off the shelf product, they just call the 
    manufacturer and ask them to fix it."
    
    But I assume that there are substantial limits as to what "fix" means.  
    This could be problematic especially if the solution ends up not 
    satisfying the needs of the customer.
    
    Greg: "State agencies, and the people working for them, are often 
    immune from private lawsuits unless the legislation authorizing the 
    agency allows for such suits."
    
    Yup.  It's called sovereign immunity.  While individuals wouldn't 
    likely be able to obtain damages, but they can sure sue the state to 
    enjoin the agency from engaging in certain behaviors.
    
    Warren: I'd also argue that part of secure software is good software 
    design.  If you're designing a software app, to be as secure as it can 
    be, you have to have security in mind at the beginning of the 
    development of the design.  Security can't be an afterthought.
    
    Brian:   ID theft is a big issue for me, and I think the state has to 
    take an active role in preventing it by increasing penalties for it and 
    making it more difficult for thieves to obtain the information 
    necessary to undertake their crimes.
    



    This archive was generated by hypermail 2b30 : Thu Sep 26 2002 - 17:34:25 PDT