Breaking News
Blog

Engineer vs. Hacker Quandary

NO RATINGS
Page 1 / 2 Next >
View Comments: Oldest First | Newest First | Threaded View
<<   <   Page 2 / 5   >   >>
junko.yoshida
User Rank
Blogger
Re: Think like a hacker
junko.yoshida   7/26/2013 2:00:31 PM
NO RATINGS
RichQ, thanks for your detailed description here. 

If you need to design a new automotive MCU which is supposed to address the potential hacking issues (i.e. your next car might be attacked by malicious hackers, thus your car might be getting externally controlled somehow), which types of hackers do you need to deal with the issue?

Rather than thinking "that would never happen" (which many engineers said), we need someone who can totally think out of box, and say, "let me hack it," right?

So, in your definition, do that guy belong to the first or second type?

I would say the second type. 

 

 

junko.yoshida
User Rank
Blogger
Re: Hackers and test engineers
junko.yoshida   7/26/2013 2:04:31 PM
NO RATINGS
Most of the publicized exploits I can think of offhand are in legacy code first written before hacking became common.  It simply didn't occur to the developers that someone mightdeliberately try to overflow a buffer with bad intent.

This is very informative. Now I get it. Thank you.

junko.yoshida
User Rank
Blogger
Re: Hackers and test engineers
junko.yoshida   7/26/2013 2:04:32 PM
NO RATINGS
Most of the publicized exploits I can think of offhand are in legacy code first written before hacking became common.  It simply didn't occur to the developers that someone mightdeliberately try to overflow a buffer with bad intent.

This is very informative. Now I get it. Thank you.

DMcCunney
User Rank
CEO
Re: Hackers and test engineers
DMcCunney   7/26/2013 2:13:12 PM
NO RATINGS
You're welcome.

Note that hacking will still occur, because code will never be perfect.  I'm following a couple of developments now where a requirement is that if you submit code, you submit tests that can verify the code as well.  But that's not yet the norm, and even when it is, there will be areas of vulnerability.  What happens when the vulnerable spot is interactions between pieces of code?  Testing all of the possible interactions between sections of code may be an order of magnitude harder than verifying the robustness of any individual module.

All you can realistically do is raise the bar and make it harder to exploit your code, by testing as thoroughly as you can before putting it into production.

RichQ
User Rank
Staff
Re: Think like a hacker
RichQ   7/26/2013 2:17:43 PM
NO RATINGS
I agree, you need the second type. You want someone who can look at the design and ask "can I do something annoying like honk the horn every time someone turns on the signal blinker," and then diligently dig for some way of doing it. Making the blinker sound the horn is not something most of us would even think of as a problem needing to be solved. Definitely the second kind.

LiketoBike
User Rank
CEO
Engineering/hacking differences
LiketoBike   7/26/2013 2:33:58 PM
NO RATINGS
The economic aspect (time, money) often raises its head here.  Guarding against hacking takes TIME (more testing, more code, more THINKING).  I submit that in industry, the question is often will an engineer be allowed to take the time/energy/money to think like a hacker, rather than can the engineer think that way. 

Thinking like a hacker (for the purposes of increasing robustness and resistance to "bad" hacking) is also a different aspect of the design process - more like testing, as has been mentioned.  Most traditional DESIGN engineering is "make it happen."  "Make it robust" is a different criterion, and a different cognitive state (much like writing and editing are different cognitive states).  

junko.yoshida
User Rank
Blogger
Re: Think like a hacker
junko.yoshida   7/26/2013 2:46:11 PM
NO RATINGS
Yep. Sometimes, I think, even button-down companies, and especially because they are button-down, need those annoying dudes. 

junko.yoshida
User Rank
Blogger
Re: Engineering/hacking differences
junko.yoshida   7/26/2013 2:50:54 PM
NO RATINGS
@LiketoBike, your points are well taken. It's not just a different mindset, but the right question to ask is: Can companies afford to have engineers to think like hackers? (by spending time and money)

But as system's complexity increases and everything connected to Internet, I am guessing it will eventually come down to this: Can any company afford not to have someone who can think like hackers in the future?

rich.pell
User Rank
Blogger
Re: Think like a hacker
rich.pell   7/26/2013 3:26:19 PM
NO RATINGS
Here's where something like gamification might come in handy.  As RichQ and others have noted, it's a mindset thing.  In this case what's needed may be more of a gamer mindset than that of an engineer or designer.

majortom84
User Rank
Freelancer
Re: Engineering/hacking differences
majortom84   7/26/2013 3:48:17 PM
I think we're getting closer to the center of it.  An engineer implements what's in the specification: "read some characters from the keyboard," or "convert the sensor voltage to degrees C."  That becomes our goal and we implement it in a way that is correct and reliable.  What the spec does not say, and what engineers (such as myself) fail to consider, is: "ensure an excess of characters typed cannot be written to the stack where they could form the address of a supervisory process," or perhaps "an excessive reading (say, in degrees F) must not result in rocket engine shut down during flight."  Many of us have enough trouble seeing weaknesses in design that are vulnerable to accident, nevermind a determined attack.  So indeed, we are not trained to think outside the box; in fact "outside the box" starts to sound cliched, so it might be understating the problem.

Meanwhile, a hacker's very goal (and of course I mean a hacker of the malevolent type) is to achieve the unauthorized and the unanticipated.  It's a goal that isn't even opposed to ours - it's on the Z axis when we're watching X and Y.

So then of course we are told we must consider security, and we make the doors and windows tight and bulletproof, but the hackers just come down the chimney.  Anyone remember a scene in one of the _Hitchhiker's_ books (the last one, I think) where one of the characters (Ford, probably) gains access to a secure building simply by opening a window?  He found himself suspended (I forget how or why) outside one of the higher floors, and reasoned that what the building designers did not expect was for him to be there at all...

Can we engineers be taught to think that way?  Probably, but I think we can agree it's not about designing an encryption key with more bits.  In fact I wonder if there's any such thing as a course or book anywhere that teaches this kind of lesson!

 

<<   <   Page 2 / 5   >   >>
August Cartoon Caption Winner!
August Cartoon Caption Winner!
"All the King's horses and all the KIng's men gave up on Humpty, so they handed the problem off to Engineering."
5 comments
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll
Radio
LATEST ARCHIVED BROADCAST
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.