Deadlines are a fact of life in the corporate world. A good manager will have a phased plan that delivers a minimal product that will be enough to meet a given deadline - this minimal product is not expected to have much creativity or innovation. However, future plans should allocate a portion of the engineer's time to improve the product without the strict deadlines or even goals over an extended period, say 10% of their time (i.e. half a day per week) for as long as the product is supported.
Most engineers don't have any problems doing this - be it to simply refactor/cleanup code, find more efficient algorithms, and once in a while they might surprise everyone with an innovative addition. The more important aspect of this improvement phase is the process in which the engineer went about the task. E.g. an engineer discovers at the end of the exercise that they were not able to improve on scalability of the existing product, is in itself useful, because they managed to demonstate that the existing implemention is actually scalable. Some times they will encounter a problem or an improvement effort that will take more of their time or assistance from several other team members - this is usually a good thing.
Got to read Linus' comment in context of his post, otherwise it's a gross generalization where you're just arguing about semantics and opinions.
A better summarization of what Linus said is: take into account security aspects when designing a feature, so you don't rely on a kernel panic (or exceptions) when some rule is not observed.
Here is something analogous I ran into recently regarding a Java SDK that was not designed with security in mind. Java has a SealedObject to protect sensitive data while in memory - great feature, but then things got messy when it came to dealing with String instances. In Java it is considered bad practice to use String type to represent any kind of sensitive data like passwords because the String is immutable (i.e. it can be visible in the heap for quite a while before getting garbage collected, and if a heap dump is triggered you are screwed). What it boiled down to was the current SDK had signatures like the following:
setPassword(String pwd);// BAD!!!
instead of:
setPassword(char[] pwd);// better!
If the SDK was designed with setPassword(char[]) to begin with, SealedObject library usage would have been much simpler and cleaner - no silly security rules. But thanks to cluelessness of setPassword(String) in the SDK, SealedObject library design became much messier due to security rule to throw an exception whenever it encountered String instances were used to represent sensitive data.
I use Kaspersky at home. During my research, I looked up what malware Kaspersky Labs had discovered and wanted to see if they'd be bold enough to uncover any Russian state sponsored malware - there weren't any, while they did discover several with links back to NSA and Israel - interesting, but didn't think much more of it.
Best case scenario is that Kaspersky do not have ties to government, but they're not stupid enough to reveal Russian state sponsored malware either (if they did so publically, I can't imagine them being allowed to operate in Russia). What this means is you cannot count on Kaspersky to protect you from malware developed by Russian authorities (at least not until they're public knowledge), but then again, it is unlikely any commercial product would either.
A year or two ago Microsoft offered our company money and even some engineers to help to port our mobile product to Windows phone. Since we were really strapped for engineering resources, which we would still have to devote to the port despite the assistance, but not short on cash, we turned them down because we felt our other priorities were more important than Windows phone. We must have been the minority to do so because they were incredulous at our rejection. Just as well it seems.
The investigation concluded that WoSign knowingly and intentionally misissued certificates in order to circumvent browser restrictions and CA requirements. Further, it determined that StartCom, another CA, had been purchased by WoSign, and had replaced infrastructure, staff, policies, and issuance systems with WoSign's. When presented with this evidence, WoSign and StartCom management actively attempted to mislead the browser community about the acquisition and the relationship of these two companies. For both CAs, we have concluded there is a pattern of issues and incidents that indicate an approach to security that is not in concordance with the responsibilities of a publicly trusted CA.
Rockefeller family is big - note that only RFF made that announcement, not jointly with all their other funds or the foundation. It is still a grand gesture, and clearly makes a strong political statement, but I doubt the monetary impact is anywhere close to the Rockefeller foundation. The Rockefeller Foundation - Founded in 1913, this is the famous philanthropic organization set up by Senior and Junior. Endowment of 3.4 billion. The Rockefeller Brothers Fund - Founded in 1940 by the third-generation's five sons and one daughter of Junior. Endowment of 811 million. The Rockefeller Family Fund - Founded in 1967 by members of the family's fourth-generation. Endowment ?
I strongly recommend for anyone considering a computer science degree to pick a dual major.
Mine was a hybrid telecommunications engineering and computer science degree - it was very interesting to observe those of us who clearly enjoyed programming and had the knack for it would elect for increasingly more programming and computer science oriented courses, while those who didn't had many other good course options. In our course of about 35 people, about half had the knack for programming while the other half always seem to need help.
Right or wrong my impression of unions are that they are catered towards less skilled labor, while professions require a lot more skill that can be encapsulated by many certifications. Lawyers with their bar and accountants with their CPA are examples. I've no doubt many of us can easily come up with a fairly basic curriculum for basic certification - take for example Secure Coding practices. Given how diverse and specialized a lot of our work can be, I imagine a lot of esoteric certificates can be devised. Certifications would likely need to be renewed from time to time as well, considering how quickly technologies and techniques evolve. A profession centered around good education benefits everyone.
Reading through the website, it seems the reason they're shutting down is because the current Executive Director is stepping down, and they haven't found anyone that's a good fit, or those who are a good fit don't want the job.
Reading through the job description - I think it kind of sucks. Salary 120k-160k which is apparently the market rate for this sort of position in San Francisco - doesn't seem very much. And the following paragraph jumped out:
While this job is fulfilling and supportive in many ways, it also has some serious downsides. As the visible leader of a feminist activism organization, many people will feel entitled to your time and energy without compensation and you will need to tell them no frequently so that we can fulfill our mission. We will provide you with experienced support in handling harassment and threats, as you will almost certainly be the target of these. Sometimes partners, sponsors, donors, or community members will pressure the Ada Initiative to do things contrary to its mission and you will need to stand up to them. Listening to and responding to reports of sexual violence, intimate partner violence, and criminal harassment are a frequent part of the job.
The credit card system works pretty well - so easy to use that family members usually don't have any trouble using each other's cards. Behind the scenes however, there are comprehensive fraud detection systems, as well as clear responsibilities of fraud liability (usually card issuer).
I agree with another poster who mentioned that the onus of security should be mainly on the system - much more than the end user. What this means is that if you're going to setup any kind of password or multi-factor authentication system, it must be relatively easy to use. But then ensure there's an intrusion system in place that works in a similar manner to credit card fraud detection, where anomalies are quickly flagged and escalated for investigation.
The final project of this VLSI elective course I took required each team to build three logical modules that would work together. I was responsible for the control and integration portion bringing together all the logical modules. I spent an entire sleepless night sorting out the issues. Our team was the only one that had a functioning chip (simulated) in the end. The lecturer wasn't surprised - most chips of any reasonable complexity require A LOT of painstaking (e.g. efficient routing, interference) work to get them working - often requiring certain modules to be pulled apart (or redesigned) so they integrate better with others.
Actually, if you're willing to take a risk and join a startup and have stock options, you can stand to gain an incredible amount. Most startups fail, but finding another job shouldn't be a problem.
What I suggest is to first find a relatively large stable corporation to work for after graduation. After 3-5 years experience, join a startup (do your research on them first of course) or a relatively new company that is planning to go public, and negotiate a nice chunk of stock options. It is likely there will be many long nights at work, but the energy and vibrancy will sustain you. Don't get married too early - if the relationship gets serious, live with each other for at least two years, and get a prenup.
Best area for this sort of lifestyle is still the US west coast, home of the venture capitalists.
But as another poster noted, it helps to have a certain love for this field that extends into your personal life - technologies evolve quickly enough that you should be constantly learning. From my fifteen years plus experience as a software engineer, there are very few people who have this sort of passion. Most prefer to settle into doing the same thing day in day out - their priorities shift elsewhere like to their families - the good news is that most larger companies need people like that, and still pay a decent salary.
I wonder how many of you find the faith based approach of many audiophiles silly (or disturbing). Nevertheless, it's amazing how large the audio industry has grown, in effect selling snake oil. For those of you who have not heard of NwAvGuy, he's an electronics engineer (most likely specializing in audio) who called BS on the racket - ran his own analysis to debunk expensive headphone amplifiers, and went so far as coming up with a cheap yet excellent reference design.
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.
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.
Slashdot Mirror
Deadlines are a fact of life in the corporate world. A good manager will have a phased plan that delivers a minimal product that will be enough to meet a given deadline - this minimal product is not expected to have much creativity or innovation. However, future plans should allocate a portion of the engineer's time to improve the product without the strict deadlines or even goals over an extended period, say 10% of their time (i.e. half a day per week) for as long as the product is supported.
Most engineers don't have any problems doing this - be it to simply refactor/cleanup code, find more efficient algorithms, and once in a while they might surprise everyone with an innovative addition. The more important aspect of this improvement phase is the process in which the engineer went about the task. E.g. an engineer discovers at the end of the exercise that they were not able to improve on scalability of the existing product, is in itself useful, because they managed to demonstate that the existing implemention is actually scalable. Some times they will encounter a problem or an improvement effort that will take more of their time or assistance from several other team members - this is usually a good thing.
Got to read Linus' comment in context of his post, otherwise it's a gross generalization where you're just arguing about semantics and opinions.
A better summarization of what Linus said is: take into account security aspects when designing a feature, so you don't rely on a kernel panic (or exceptions) when some rule is not observed.
Here is something analogous I ran into recently regarding a Java SDK that was not designed with security in mind. Java has a SealedObject to protect sensitive data while in memory - great feature, but then things got messy when it came to dealing with String instances. In Java it is considered bad practice to use String type to represent any kind of sensitive data like passwords because the String is immutable (i.e. it can be visible in the heap for quite a while before getting garbage collected, and if a heap dump is triggered you are screwed). What it boiled down to was the current SDK had signatures like the following:
setPassword(String pwd); // BAD!!!
instead of:
setPassword(char[] pwd); // better!
If the SDK was designed with setPassword(char[]) to begin with, SealedObject library usage would have been much simpler and cleaner - no silly security rules. But thanks to cluelessness of setPassword(String) in the SDK, SealedObject library design became much messier due to security rule to throw an exception whenever it encountered String instances were used to represent sensitive data.
I use Kaspersky at home. During my research, I looked up what malware Kaspersky Labs had discovered and wanted to see if they'd be bold enough to uncover any Russian state sponsored malware - there weren't any, while they did discover several with links back to NSA and Israel - interesting, but didn't think much more of it.
Best case scenario is that Kaspersky do not have ties to government, but they're not stupid enough to reveal Russian state sponsored malware either (if they did so publically, I can't imagine them being allowed to operate in Russia). What this means is you cannot count on Kaspersky to protect you from malware developed by Russian authorities (at least not until they're public knowledge), but then again, it is unlikely any commercial product would either.
Before donating to any such charities, please do a quick search with charitynavigator or charitywatch:
https://www.charitynavigator.o...
https://www.charitywatch.org/
A year or two ago Microsoft offered our company money and even some engineers to help to port our mobile product to Windows phone. Since we were really strapped for engineering resources, which we would still have to devote to the port despite the assistance, but not short on cash, we turned them down because we felt our other priorities were more important than Windows phone. We must have been the minority to do so because they were incredulous at our rejection. Just as well it seems.
It wasn't a "small" mistake.
The investigation concluded that WoSign knowingly and intentionally misissued certificates in order to circumvent browser restrictions and CA requirements. Further, it determined that StartCom, another CA, had been purchased by WoSign, and had replaced infrastructure, staff, policies, and issuance systems with WoSign's. When presented with this evidence, WoSign and StartCom management actively attempted to mislead the browser community about the acquisition and the relationship of these two companies. For both CAs, we have concluded there is a pattern of issues and incidents that indicate an approach to security that is not in concordance with the responsibilities of a publicly trusted CA.
https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html
Rockefeller family is big - note that only RFF made that announcement, not jointly with all their other funds or the foundation. It is still a grand gesture, and clearly makes a strong political statement, but I doubt the monetary impact is anywhere close to the Rockefeller foundation.
The Rockefeller Foundation - Founded in 1913, this is the famous philanthropic organization set up by Senior and Junior. Endowment of 3.4 billion.
The Rockefeller Brothers Fund - Founded in 1940 by the third-generation's five sons and one daughter of Junior. Endowment of 811 million.
The Rockefeller Family Fund - Founded in 1967 by members of the family's fourth-generation. Endowment ?
I strongly recommend for anyone considering a computer science degree to pick a dual major.
Mine was a hybrid telecommunications engineering and computer science degree - it was very interesting to observe those of us who clearly enjoyed programming and had the knack for it would elect for increasingly more programming and computer science oriented courses, while those who didn't had many other good course options. In our course of about 35 people, about half had the knack for programming while the other half always seem to need help.
I'm on the side of moving software engineering towards a Profession rather than Unionization.
Right or wrong my impression of unions are that they are catered towards less skilled labor, while professions require a lot more skill that can be encapsulated by many certifications. Lawyers with their bar and accountants with their CPA are examples. I've no doubt many of us can easily come up with a fairly basic curriculum for basic certification - take for example Secure Coding practices. Given how diverse and specialized a lot of our work can be, I imagine a lot of esoteric certificates can be devised. Certifications would likely need to be renewed from time to time as well, considering how quickly technologies and techniques evolve. A profession centered around good education benefits everyone.
Reading through the website, it seems the reason they're shutting down is because the current Executive Director is stepping down, and they haven't found anyone that's a good fit, or those who are a good fit don't want the job.
Reading through the job description - I think it kind of sucks. Salary 120k-160k which is apparently the market rate for this sort of position in San Francisco - doesn't seem very much. And the following paragraph jumped out:
While this job is fulfilling and supportive in many ways, it also has some serious downsides. As the visible leader of a feminist activism organization, many people will feel entitled to your time and energy without compensation and you will need to tell them no frequently so that we can fulfill our mission. We will provide you with experienced support in handling harassment and threats, as you will almost certainly be the target of these. Sometimes partners, sponsors, donors, or community members will pressure the Ada Initiative to do things contrary to its mission and you will need to stand up to them. Listening to and responding to reports of sexual violence, intimate partner violence, and criminal harassment are a frequent part of the job.
The credit card system works pretty well - so easy to use that family members usually don't have any trouble using each other's cards. Behind the scenes however, there are comprehensive fraud detection systems, as well as clear responsibilities of fraud liability (usually card issuer).
I agree with another poster who mentioned that the onus of security should be mainly on the system - much more than the end user. What this means is that if you're going to setup any kind of password or multi-factor authentication system, it must be relatively easy to use. But then ensure there's an intrusion system in place that works in a similar manner to credit card fraud detection, where anomalies are quickly flagged and escalated for investigation.
The final project of this VLSI elective course I took required each team to build three logical modules that would work together. I was responsible for the control and integration portion bringing together all the logical modules. I spent an entire sleepless night sorting out the issues. Our team was the only one that had a functioning chip (simulated) in the end. The lecturer wasn't surprised - most chips of any reasonable complexity require A LOT of painstaking (e.g. efficient routing, interference) work to get them working - often requiring certain modules to be pulled apart (or redesigned) so they integrate better with others.
Actually, if you're willing to take a risk and join a startup and have stock options, you can stand to gain an incredible amount. Most startups fail, but finding another job shouldn't be a problem.
What I suggest is to first find a relatively large stable corporation to work for after graduation. After 3-5 years experience, join a startup (do your research on them first of course) or a relatively new company that is planning to go public, and negotiate a nice chunk of stock options. It is likely there will be many long nights at work, but the energy and vibrancy will sustain you. Don't get married too early - if the relationship gets serious, live with each other for at least two years, and get a prenup.
Best area for this sort of lifestyle is still the US west coast, home of the venture capitalists.
But as another poster noted, it helps to have a certain love for this field that extends into your personal life - technologies evolve quickly enough that you should be constantly learning. From my fifteen years plus experience as a software engineer, there are very few people who have this sort of passion. Most prefer to settle into doing the same thing day in day out - their priorities shift elsewhere like to their families - the good news is that most larger companies need people like that, and still pay a decent salary.
I wonder how many of you find the faith based approach of many audiophiles silly (or disturbing). Nevertheless, it's amazing how large the audio industry has grown, in effect selling snake oil. For those of you who have not heard of NwAvGuy, he's an electronics engineer (most likely specializing in audio) who called BS on the racket - ran his own analysis to debunk expensive headphone amplifiers, and went so far as coming up with a cheap yet excellent reference design.
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.