Loading ...
Sorry, an error occurred while loading the content.

security, agility, and usability

Expand Messages
  • Larry Constantine
    The front-page headlines in the Sunday New York Times once again brought the story of the Stuxnet software attack on Iran s nuclear facilities to the forefront
    Message 1 of 6 , Jan 18, 2011
    • 0 Attachment

      The front-page headlines in the Sunday New York Times once again brought the story of the Stuxnet software attack on Iran ’s nuclear facilities to the forefront (http://www.nytimes.com/2011/01/16/world/middleeast/16stuxnet.html ). The deconstruction by my German colleague Ralph Langner not only has teased out essentially all of the detailed functioning of the Stuxnet code itself, but also has uncovered clues to the larger story of who was involved in the operation and how it was accomplished. In a sense, the headlines trumped the storyline of the just-released Lior Samson novel, Web Games. (For an analysis and the connection with Stuxnet, see the blog at www.liorsamson.com/onwords.html.)

      I want to raise two questions that could be relevant to this group. One element of the attack vector directly relates to user experience, as the Stuxnet code was able to insinuate itself into a man-in-the-middle position and effectively fool the operators into believing that everything was operating normally when, in fact, the centrifuges were in the process of tearing themselves apart. One question is whether there might be architectures or programming practices or interaction designs that make such exploits more difficult or less likely to succeed.

      A second question is whether agile development has any special role to play or anything particular to offer in terms of contributing to software and hardware security.

       

      Thoughts?

      --Larry Constantine, IDSA, ACM Fellow
        Professor |  University of Madeira | Funchal , Portugal
        Institute Fellow | Madeira Interactive Technologies Institute | www.M-ITI.org


        Fiction “to feed the inner nerd” – Bashert , Web Games, and  The Dome, political thrillers from Lior Samson | www.LiorSamson.com

       

    • Adam Sroka
      I am not a security expert, and I m not very familiar with the story, so I won t comment on those parts. I do know a thing or two about Agile, and I am pretty
      Message 2 of 6 , Jan 18, 2011
      • 0 Attachment
        I am not a security expert, and I'm not very familiar with the story, so I won't comment on those parts. I do know a thing or two about Agile, and I am pretty confident in saying that it would help (at the very least it wouldn't hurt ;-) 

        I think the benefit of Agile in this situation is that it encourages you to put the folks who know about security and the folks who know about UX together in the same room with the folks who know the product and the folks with other technical skills. That way they can participate together in every phase of defining, implementing, and testing the product. 

        Of course, there is no guarantee that a security expert paired with a UX expert would think of the scenario that caused the vulnerability that was exploited. However, it seems obvious to me that they would have a better chance of coming up with it than the average programmer working in isolation. Agile tells us to get the right people and bring them closely together as a team. This seems like good advice for this scenario. 

        On Tue, Jan 18, 2011 at 10:26 AM, Larry Constantine <lconstantine@...> wrote:
         

        The front-page headlines in the Sunday New York Times once again brought the story of the Stuxnet software attack on Iran’s nuclear facilities to the forefront (http://www.nytimes.com/2011/01/16/world/middleeast/16stuxnet.html). The deconstruction by my German colleague Ralph Langner not only has teased out essentially all of the detailed functioning of the Stuxnet code itself, but also has uncovered clues to the larger story of who was involved in the operation and how it was accomplished. In a sense, the headlines trumped the storyline of the just-released Lior Samson novel, Web Games. (For an analysis and the connection with Stuxnet, see the blog at www.liorsamson.com/onwords.html.)

        I want to raise two questions that could be relevant to this group. One element of the attack vector directly relates to user experience, as the Stuxnet code was able to insinuate itself into a man-in-the-middle position and effectively fool the operators into believing that everything was operating normally when, in fact, the centrifuges were in the process of tearing themselves apart. One question is whether there might be architectures or programming practices or interaction designs that make such exploits more difficult or less likely to succeed.

        A second question is whether agile development has any special role to play or anything particular to offer in terms of contributing to software and hardware security.

         

        Thoughts?

        --Larry Constantine, IDSA, ACM Fellow
          Professor | University of Madeira | Funchal, Portugal
          Institute Fellow | Madeira Interactive Technologies Institute | www.M-ITI.org


          Fiction “to feed the inner nerd” – Bashert , Web Games, and  The Dome, political thrillers from Lior Samson | www.LiorSamson.com

         


      • William Pietri
        ... In addition, I think a few other things help security. The biggest is the iterative nature of things. On waterfall projects, security is often an initial
        Message 3 of 6 , Jan 18, 2011
        • 0 Attachment
          On 01/18/2011 10:46 AM, Adam Sroka wrote:
          I think the benefit of Agile in this situation is that it encourages you to put the folks who know about security and the folks who know about UX together in the same room with the folks who know the product and the folks with other technical skills. That way they can participate together in every phase of defining, implementing, and testing the product. 


          In addition, I think a few other things help security.

          The biggest is the iterative nature of things. On waterfall projects, security is often an initial point of discussion or an afterthought (e.g., as part of a security review at the end), but rarely is it a pervasive concern. If you are releasing early and often, you have more opportunities to consider security issues and fix them. That can bake security consciousness into the team in a way that a non-iterative project has a hard time matching.

          Another is quality. With one giant release, quality problems aren't noticed until the end. With small, frequent releases, quality problems become apparent. More than that, it's hard to keep iterating on a low-quality code base, giving people a strong incentive to keep things solid. Agile methods, Extreme Programming in particular, have a variety of techniques for achieving and maintaining high quality. Since a lot of security holes come through bugs, this is of high value.

          A third is iterative software design. The Agile community, through focusing on things like refactoring, DRY, and DDD, encourages clear software architectures. Aesthetic appeal aside, keeping the architecture clean makes new work easier. But from a security perspective, high architectural integrity makes it easier to reason about a system, and easier to add security checks to the places that need them.

           But yes, I think the biggest fix is just getting all the people who matter together in a room and having them frequently produce something useful. That forces them to interact in ways no ritual-driven process can achieve.

          William
        • Mike Dwyer
          Dear Lior Sorry to hear that reality caught up with your latest work. I was looking forward to the book much more than the news. Now, how can I do laps in the
          Message 4 of 6 , Jan 18, 2011
          • 0 Attachment

            Dear Lior

            Sorry to hear that reality caught up with your latest work. I was looking forward to the book much more than the news.  Now, how can I do laps in the river of De-Nile, pretending all was a work of fiction?  The NYT and every blog is emptying the river,  This sucks. 8^)

             

            Sadly, The world is moving too fast for us to actually do our best.  Maybe that is the problem with the whole UX thing, things move to fast these days to allow for much more than a activity pattern match and exception handling.  When we do that in UX it is the same as creating a huge heuristic state engine between the ears.  The problem is that what is between our ears is a 4bit OS we have embedded in us from our genome legacy to process all the information it takes in.  The rub is most of that data doesn’t fit in binaries needed for a cool UX, so we never get to use it. 

            Perhaps the base issue for security is the same one we face with our kids.   I mean how many of us say “Get your heads out of the video game and go do something.”  What would have happened to the Iranian systems if they had some one walking around looking at real gauges and listening with real ears and had a human nose picking up the scent of things grinding away.

             

             

            Mike Dwyer


            "Planning constantly peers into the future for indications as to where a solution may emerge."

            "A Plan is a complex situation, adapting to an emerging solution." 

             

            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Larry Constantine
            Sent: Tuesday, January 18, 2011 1:27 PM
            To: agile-usability@yahoogroups.com
            Subject: [agile-usability] security, agility, and usability

             

             

            The front-page headlines in the Sunday New York Times once again brought the story of the Stuxnet software attack on Iran’s nuclear facilities to the forefront (http://www.nytimes.com/2011/01/16/world/middleeast/16stuxnet.html). The deconstruction by my German colleague Ralph Langner not only has teased out essentially all of the detailed functioning of the Stuxnet code itself, but also has uncovered clues to the larger story of who was involved in the operation and how it was accomplished. In a sense, the headlines trumped the storyline of the just-released Lior Samson novel, Web Games. (For an analysis and the connection with Stuxnet, see the blog at www.liorsamson.com/onwords.html.)

            I want to raise two questions that could be relevant to this group. One element of the attack vector directly relates to user experience, as the Stuxnet code was able to insinuate itself into a man-in-the-middle position and effectively fool the operators into believing that everything was operating normally when, in fact, the centrifuges were in the process of tearing themselves apart. One question is whether there might be architectures or programming practices or interaction designs that make such exploits more difficult or less likely to succeed.

            A second question is whether agile development has any special role to play or anything particular to offer in terms of contributing to software and hardware security.

             

            Thoughts?

            --Larry Constantine, IDSA, ACM Fellow
              Professor | University of Madeira | Funchal, Portugal
              Institute Fellow | Madeira Interactive Technologies Institute | www.M-ITI.org


              Fiction “to feed the inner nerd” – Bashert , Web Games, and  The Dome, political thrillers from Lior Samson | www.LiorSamson.com

             

          • Larry Constantine
            ... You can still enjoy the read, particularly as it is about a still largely unacknowledged threat in which we in the U.S. are particularly vulnerable. Do buy
            Message 5 of 6 , Jan 18, 2011
            • 0 Attachment

              Mike Dwyer said:

               

              > I was looking forward to the book much more than the news. <

               

              You can still enjoy the read, particularly as it is about a still largely unacknowledged threat in which we in the U.S. are particularly vulnerable. Do buy the book. (Am I allowed to say that?)

               

              And Mike said:

               

              > What would have happened to the Iranian systems if they had some one walking around looking at real gauges and listening with real ears and had a human nose picking up the scent of things grinding away. <

               

              This is a concrete architectural suggestion similar to ones I have thought about. It’s based on the principle of redundant communication. If there is a hardwired analog gauge visible to someone walking around and it doesn’t match the HMI display, then somebody might notice and might take some action before the 984th centrifuge spins out of control.

               

              One of the problems is that in many cases (this being one of them), there is no meaning to the concept of “hardwired” or “analog.” It occurs to me that something like that might be accomplished by cheating, violating the layered architecture that separates the presentation layer from the model and the controlled equipment. If the HMI layer could directly read a signal from the equipment over a different wire, it might be harder to intercept both with a simple software exploit. Another approach might be to build a small PLC system into the equipment itself with its program burned into a PROM and it’s small display welded to the case. Makes updating harder, but that is precisely the idea—it could not be digitally compromised, only physically.

               

              Adam Sroka and William Petri suggested that getting the various specialties in the same room is a step in the right direction. I agree, but this has little or nothing to do with agile development. I’ve been part of (dare I say it?) waterfall projects that used this kind of teamwork to good effect. The “agile means quality” argument is also appealing, but quality in the sense of security will be improved only to the extent it is explicitly attended to. It’s Weinberg’s Law: Whatever you measure or pay attention to is improved. Again, it applies to all development approaches.

               

              I do wonder if pair programming paired with multi-disciplinary design might make a good lever, particularly if each pair is charged with watching for security flaws as well as coding defects. So-called pen-testing (penetration testing to identify security flaws) might be made part of test-first development. Or maybe it would have to be built into system regression tests?

               

              Of course, the vulnerabilities in industrial control systems are as much in hardware and fundamental PLC architecture as in software, so radically more secure systems will require integral hardware-software design and development teams—lean engineering with agile software development. Now there’s an idea!

              --Larry Constantine, IDSA, ACM Fellow
                Professor |  University of Madeira | Funchal , Portugal
                Institute Fellow | Madeira Interactive Technologies Institute | www.M-ITI.org


                Fiction “to feed the inner nerd” – Bashert , Web Games, and  The Dome, political thrillers from Lior Samson | www.LiorSamson.com

               

            • Mike Dwyer
              The book is on my buy list, Larry. When I do read it - and enjoy it - I will write you. It isn t just the redundancy, that have someone walking around
              Message 6 of 6 , Jan 18, 2011
              • 0 Attachment

                The book is on my buy list, Larry.  When I do read it – and enjoy it – I will write you.

                It isn’t just the redundancy, that have someone walking around provides.  There is 10,000 to 100,000 years of genetic refinement of a system that has adapted and inspected over that period of time and continues to do so today.  A UX should not –cannot be – something to replace the heuristics that happen between the ears.  The UX must augment.

                Take the helmet in the Warfighter, every feature and function acts as a force multiplier and it is designed to be accessible as the person does their job.  Or the thermal ‘goggles’ most firefighters have access to.  They ‘see through walls’ showing people, hotspots, and even warm pizza!  But the firefighter is the one that acts because their eyes are behind the goggles and their brains are processing the information.

                 

                In short a really sophisticated UX can lull the brain into a false sense of predicted events.  That sir is what to exploit if you want a successful infiltration.  In this perspective, the more stuff you put in to track what is happening, the easier it is to create the illusion, because what is expected is already on the other side of the wire.  All we need to do is strip the timestamp and run a loop or a delay. 

                 

                Do I think Agile has a place in solving this – most definitely, but it isn’t necessarily in elegantly delivered code built by the best people who can code.  I firmly believe Agile works best when it builds enough support – at any one time – to leverage the skills and capabilities of the people doing the job.  To do that you need to put the ‘doer’ at the very front and build to meet their needs.  Lean manufacturing also has an impact, if we keep in mind to limit only what you do to what has been agreed to.

                 

                From a systems perspective,  Agile needs to change gears, IMO.  The software we are so proud becomes a part of the solution, going lean would mean taking our seat in the bus of specialized skills who make the ‘doer’ a winner.  What we need to understand that the systems view looks at what happens before, during, and after the ‘tooling’ is done.  Once we do that and invite the other ‘specialized skills’ to the table – and listen to them – we can begin to improve the security, safety, and sanity of what people do to get the job done.

                 

                 

                 

                Mike Dwyer


                "Planning constantly peers into the future for indications as to where a solution may emerge."

                "A Plan is a complex situation, adapting to an emerging solution." 

                 

                From: Larry Constantine [mailto:lconstantine@...]
                Sent: Tuesday, January 18, 2011 5:20 PM
                To: agile-usability@yahoogroups.com
                Cc: 'Mike Dwyer'
                Subject: RE: [agile-usability] security, agility, and usability

                 

                Mike Dwyer said:

                 

                > I was looking forward to the book much more than the news. <

                 

                You can still enjoy the read, particularly as it is about a still largely unacknowledged threat in which we in the U.S. are particularly vulnerable. Do buy the book. (Am I allowed to say that?)

                 

                And Mike said:

                 

                > What would have happened to the Iranian systems if they had some one walking around looking at real gauges and listening with real ears and had a human nose picking up the scent of things grinding away. <

                 

                This is a concrete architectural suggestion similar to ones I have thought about. It’s based on the principle of redundant communication. If there is a hardwired analog gauge visible to someone walking around and it doesn’t match the HMI display, then somebody might notice and might take some action before the 984th centrifuge spins out of control.

                 

                One of the problems is that in many cases (this being one of them), there is no meaning to the concept of “hardwired” or “analog.” It occurs to me that something like that might be accomplished by cheating, violating the layered architecture that separates the presentation layer from the model and the controlled equipment. If the HMI layer could directly read a signal from the equipment over a different wire, it might be harder to intercept both with a simple software exploit. Another approach might be to build a small PLC system into the equipment itself with its program burned into a PROM and it’s small display welded to the case. Makes updating harder, but that is precisely the idea—it could not be digitally compromised, only physically.

                 

                Adam Sroka and William Petri suggested that getting the various specialties in the same room is a step in the right direction. I agree, but this has little or nothing to do with agile development. I’ve been part of (dare I say it?) waterfall projects that used this kind of teamwork to good effect. The “agile means quality” argument is also appealing, but quality in the sense of security will be improved only to the extent it is explicitly attended to. It’s Weinberg’s Law: Whatever you measure or pay attention to is improved. Again, it applies to all development approaches.

                 

                I do wonder if pair programming paired with multi-disciplinary design might make a good lever, particularly if each pair is charged with watching for security flaws as well as coding defects. So-called pen-testing (penetration testing to identify security flaws) might be made part of test-first development. Or maybe it would have to be built into system regression tests?

                 

                Of course, the vulnerabilities in industrial control systems are as much in hardware and fundamental PLC architecture as in software, so radically more secure systems will require integral hardware-software design and development teams—lean engineering with agile software development. Now there’s an idea!

                --Larry Constantine, IDSA, ACM Fellow
                  Professor | University of Madeira | Funchal, Portugal
                  Institute Fellow | Madeira Interactive Technologies Institute | www.M-ITI.org


                  Fiction “to feed the inner nerd” – Bashert , Web Games, and  The Dome, political thrillers from Lior Samson | www.LiorSamson.com

                 

              Your message has been successfully submitted and would be delivered to recipients shortly.