Secure software development is something I've gotten into recently, and the growth potential there is excellent. Become familiar with BSIMM (Build Security In Maturity Model), in particular what they categorize as the SSG (Software Security Group). Here are some highlights from their document about the SSG:

The best SSG members are software security people, but software security people are often impossible to find. If you must create software security types from scratch, start with developers and teach them about security. Do not attempt to start with network security people and teach them about software, compilers, SDLCs, bug tracking, and everything else in the software universe. No amount of traditional security knowledge can overcome software cluelessness.

Seems to me that's the fault of the college/university for not teaching these concepts.

A good syllabus will teach students enough important concepts, and how to think with these concepts. It will also recognize different languages being better for teaching different aspects of CS. High level languages like Haskell are excellent for teaching algorithms. Prolog/Lisp for AI. C and assembly for low level concepts. Java IMO would be good for teaching concurrency/threading. At the end of the day, the student will be able to express the core portion of quicksort in a single line of code with Haskell, yet be able to convert it to Java, C or even assembly - and understand why you might need to do so, and the additional factors needed in lower level languages.

Good courses and certifications are offered by the SANS Institute (http://www.sans.org/). Black Hat organizes one of the premier security conferences, and also hosts many interesting courses (https://www.blackhat.com/). Certifications and courses provide a great way to start learning about security along with some really esoteric specialties, but if you think a certificate is suddenly going to make your software secure, you'd be sadly mistaken. To be effective in computer security, you need to constantly learn and keep up with recent developments. If I were hiring a candidate I wouldn't care about certifications as much as the effort and interest the individual exercises in the extremely broad field - some humility wouldn't hurt either.

The mindset of software developer working on secure or hardened software is also a little different - normally good developers focus on aspects such as clean design, extensible architecture, performance, and efficiency, but few tend to be aware of the things hackers do to exploit your code because you didn't do proper input validation, or ensure that you were protected against buffer overflows from maliciously crafted payloads.

More good resources for software developers:
- CERT coding standards (https://www.securecoding.cert.org/confluence/display/seccode/CERT+Coding+Standards)
- OWASP (https://www.owasp.org) if you're doing anything related to the internet

There's a lot to learn, which is why courses can be useful to get you started. Here are some of the things you would learn:

Security occurs at many levels. Your software is the obvious focus. Also, the application or web servers they're hosted on if any, as well as the O/S. Your software might be pretty secure, but if you do not setup your web server properly you could get screwed as well. Given the pervasive nature of SSL/TLS, you should also be aware of security vulnerabilities in openssl (if your software or servers make use of - most likely they do) and be able to understand the description and lingo used to describe the vulnerabilities. This is the more IT or sys admin oriented aspect of security. Some familiarity in this area is good.

Layered security design. Develop multiple security layers to protect your critical data. Do not rely on SSL/TLS only. Learn about public key infrastructure (asymmetric encryption algorithms), and their role with symmetric encryption algorithms like AES.

Understand what threat modeling and analysis is about. Familiarity with assurance case modeling is also interesting where you start to see the boundary between reliability and security become increasing blurry.

Do not invent your own protocols/algorithms if you can find one that already exists, especially if it has a threat analysis to accompany it. Some courses go over some of the better known protocols for things like authentication or authorization, and how to deploy them correctly.

I was taught Miranda (precursor to Haskell) some twenty years ago in my undergraduate degree. To this day I use still functional programming (Haskell) to prototype any reasonably complex algorithm.

To give you an idea of how compact functional programming languages can express complex algorithms - here's quicksort:
qsort (x:xs) = qsort (filter ( x) xs)

Couple high level functions with closure gives us a very powerful tool to express complex algorithms.

Here's what works in most practical systems with a little effort:
- Threat model. Sequence diagram of all external communication between all servers and clients. Apply STRIDE analysis. May be take a step back to see if you can simplify the workflow.
- Assurance model. State diagram of system. Capture success and error states. Unit tests for each case.

Add to that third party oversight:
- Static analysis tools.
- Third party verification.

I assume you're not developing mission critical systems that control functions in a nuclear power station, or even a car breaking system. Rather you're looking at consumer or enterprise level systems that involve some confidential, and possibly credit card information. Short deadlines and budget constraints mean you can't spend forever coming up with a solid specification or even do extensive analysis.

The way this played out in my undergraduate degree, which was a hybrid course in electronics engineering and computer science was that those of us who had a knack for programming ended up electing more and more CS subjects, while those who didn't ended with a more EE oriented course (many of those individuals went the telecommunications route rather than circuit design). Similarly, an introductory CS course could provide different tracks to allow students to focus on their strengths, i.e. while everyone is expect to do some basic programming, do not make advanced programming mandatory, but rather one out of several options.

I came to the US on an H1B back in 2000. I'm now a US citizen, even married an American. My starting pay back in 2000 was around $60k (Washington DC metro region), and is about twice that today (software engineer/architect) not counting bonuses that can add another 10-20k. I got no complaints about my salary.

Most of us in the technology group are/were H1Bs, and are now responsible for hiring new software developers. I've conducted dozens of interviews over the years (mostly entry level new grads from nearby universities) and noticed the extremely small number of American applicants (salary offered is competitive), while other departments are full of Americans (including IT). Sometimes I don't think our still smallish company would have survived or grown without the H1B program. One interesting factor about the Washington DC metro region is that it has a lot of work that requires security clearance so are only available to Americans, but I think that in turn sets a decent baseline for prevailing wages that H1Bs here benefit from.

One technology for batteries that could be developed is for a charging station to replace your electric car batteries with freshly charged ones. You could potentially be in and out faster than refueling by gas. That would be one solution to overcome the lengthy recharging.

I imagine there are still a lot of hurdles to jump over to get such a system working:
- How to design batteries so they can be replaced easily and quickly. Perhaps each car might have several sets of batteries, some of which can be easily removed, but not others. This means replacement technology can only refuel your car partially.
- Who owns the batteries? It would certainly not be the car owner under such a system - probably some sort of lease with whoever runs the charging stations.

It is a MITM vulnerability detector for TLS/SSL among other things, if I understand the intention of the tool correctly. If so, that's fantastic. For example, most TLS/SSL environments are susceptible to a large class of MITM attacks simply because their website exposes both HTTP and HTTPS so then you decide to enable SSL only (perhaps with HSTS) - but did you do it right? Perhaps this tool can tell you. How about testing out a new Certificate Pinning implementation that your lead developer claims will prevent 99% of MITM attacks? Most IT admins or enterprise developers do not have the mindset or sufficient know how to setup an environment or build a system that would slow down a determined hacker much at all.

In so far as detecting MITM attacks... I think we'll get that for free when quantum crypto arrives. But I haven't read much literature about what you're going to do about if you do detect a MITM attack on your data - if you simply stop using that channel or any other vulnerable channel then it seems you're now a victim of a DoS attack. Not saying detection like this isn't useful - on the contrary I think it opens up a whole new field of countering such threats, but right now it is much more useful to so many of us to have a good tool that can tell us whether we're indeed vulnerable to MITM attacks and ensure we setup our TLS/SSL environment properly.

Yes, according to https://github.com/google/nogo...

The best way to go about hiring is to find the best people you can for whatever salary you're offering, based solely on merit. Do so by ensuring all interviewers have undergone training on non-discrimination - they should know what questions they can and cannot ask. When interviewers discuss a candidate, they cross check one another's opinion to help minimize subjective bias. The evaluation should never involve the candidate's gender and race, among other things.

After that it shouldn't matter what the composition of your workforce is.

http://en.wikipedia.org/wiki/P...

PPE was developed by Oxford back in the 1920s because they thought a largely humanities driven syllabus centered around ancient history wasn't very practical. Many universities offer it these days, and is one of the best non-STEM courses around.

Just curious how many people have read Robert Pirsig's book(s) and subscribe to his ideas?

In a nutshell his conclusion is that the irreducible factor of life and the universe is a creation force he calls Quality. Another way to look at it is if everything is a state transition diagram, the mysterious factor is something to be found in the transitions (dynamic Quality) rather than in the states (static Quality). Akin to some aspects of Zen and Eastern philosophy. He goes on to develop these ideas to say that you can build up increasingly complex static Qualities like atomic elements, compounds, even life, from what seems like nothing... but that intangible creative dynamic Quality is there, and yet not so easy to pin down. It isn't so much a thing as it is a force.

Right or wrong I find an odd sort of comfort in this understanding.

We were taught Miranda (very similar to Haskell) in my bachelor's program. It was the primary language for most of our exercises across many courses. It is an effective lnguage for teaching many fundamental aspects of programming like recursion, and algorithms - expressing quicksort in a functional language is not only more elegant and considerably shorter when compared with c or Java. That was over twenty years ago, but to this day these functional programming abstractions have been invaluable in shaping my designs, and thought processes involving any kind of programming whatever the actual language I'm using.