Balancing the Sharing of Information

CyberSecurity Journal

Subscribe to CyberSecurity Journal: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get CyberSecurity Journal: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Security Authors: Ambuj Kumar, Shelly Palmer, Slavik Markovich, Elizabeth White, Greg Ness

Related Topics: Security Journal, CyberSecurity Journal

Blog Post

Make Security Part of Your Development Lifestyle | @DevOpsSummit #Cloud #DevOps #Security

It is my firm belief that developers today are not focused on security during periods of head-down development

It is my firm belief that developers today are not focused on security during periods of head-down development. I would love to know the percentage of web developers that know about the Open Web Application Security Project or OWASP. This non-profit organization is simply focused on the secure development of web applications. Their education and guidance is freely available to the public yet I do not read much about security in the public development circles, blogs, etc.

OWASP first published a book called the Code Review Guide in 2006. In 2006, I led a team on the development of a large web application for the administration of the Women, Infants, and Children (WIC) program for the state of Massachusetts. We were doing weekly code reviews and our focus was on best practice and quality development of the software. Quality code is secure code.

OWASP had noticed in their 2006 publication where organizations had implemented a proper code review function into their software development lifecycle (SDLC), they enjoyed remarkably better code from a security perspective. The team code review does not, however guarantee a security consideration or security focus on the architecture, designs, patterns, or methods being implemented. This consideration must come from the developers themselves.

Urgency
Throughout my career I have strived to create a sense of urgency where I have had the authority to bring about change in the organization. As a business owner, I receive about 10-15 whitepapers from various sources daily covering many IT subjects but most of these papers are communicating the need for more security in our IT infrastructures, products and services, on-premise or off. The education and intelligence of sorts is mostly marketing by organizations to provide security tools or consulting with the promise to make my business more secure. They are creating the sense of urgency here by using the psychology of fear in their publications.

Security of IT infrastructure, products, or services starts from within. Who creates these infrastructures, products, or service offerings? Your development staff, team, or group(s). They also define the level of security that protects your assets. We all need to create a sense of urgency across the entire IT department. And, it starts with you.

Culture
The culture of security is almost non-existent today. Early in my career the term DevOps did not exist. Network and development personnel were separated by the culture of the type of work they did. Networks administrators and help-desk employees protected everything. They opened and closed firewall ports. They enforced continual password changes. They required red-tape for employees that forgot those seriously secure passwords. They lived and operated within a culture of distrust. "Why do you need to change your password?", they asked. "You already have firewall access to port 80. Why do you need port 8080?", would be the question. They live a lifestyle of distrust. It seemed respectable at the time. Was the answer to security to choke the creativity of the development staff?

The development staff would operate within a culture of creativeness. If it can be done, we'll do it. The developers would figure out all the ways to bypass the in-place security practices and get the job done. In many cases, these practices were unknown to the software development manager or director. This culture still exists today within many organizations. DevOps is an attempt to place a trusted liaison between the distrusting network folks and those flip-flop-wearing, loose-cannon developers. It sounds promising. We now have a true mediating faction to resolve process conflicts between camps. Discrimination between the cultures will now be non-existent. This is not my belief.

Proposal
My proposal is a complement to DevOps. I propose we give the IT community one more acronym, and in this case, called SCALE or Security Consideration and Lifestyle Exchange. I'm going to hereafter refer to we as the shorts and flip-flops faction or software developers. We need to live a lifestyle of security consideration from now until eternity or until spoofing, tampering, repudiation, disclosure, denial of service, and elevation of privilege cease to exist, which ever comes first. The acronym SCALE was purposely spelled scale to help with conceptual thinking within this new lifestyle. If we don't always consider security vulnerabilities when we code, these inherent risks to the software, truly scale within the code-bases to which we commit. Much of the software written today is owned by an organization and not the individual developers. However, each developer needs to assume ownership of the code that she develops. And, we also need to exchange education about security as we do our code reviews and within any other discussions related to software development and security.

If you are a homeowner, you probably lock the doors at night. You take care of your home and you protect your investment. Your home is your shelter. It's safe and secure. I've had the mind-boggling opportunity to work with developers from around the world that assumed no ownership whatsoever of the code they were responsible for. That's ludicrous. This gives me the sense of urgency to correct this problem even though it's not my responsibility. It makes me want to add the bullet - accountable for the quality of your code to all these developer opportunities that ride the internet daily. Emails authored by senior talent recruiters and technical companies, that provide talent to our enterprises, and do not know what their clients really want in a software developer.

We need to consider security with every project start, code review, and subsequent release of the software. We should also do a threat model during the inception phase or just before we start development. We should do another threat model just before the first release and also discuss the model with each subsequent release. Security should be how we roll my friends. It should be our new lifestyle. Whether the code belongs to you or your employer, it should be the best that it can be. That depends on you solely.

Conclusion
I hope that you will add SCALE or Security Consideration and Lifestyle Exchange right next to the SDLC acronym in your minds. I also hope that you (we), the development community continue to move in this direction. Make the consideration of security part of your personal process. Think of it as a revolution. Don't rush the quality of your work. And, by all means, have it code reviewed. If you cheat yourself on testing code coverage, at least let a cube-mate look at it when you're done.Be a listener and learn from your seniors. Know that when you SCALE, your work doesn't add to the increasing risk of security vulnerabilities with the growth of your software repositories.

More Stories By David L. Whitehurst

David L. Whitehurst is Enterprise architect and Open-Source development expert. He has designed, implemented, and integrated enterprise IT systems, desktop applications, web applications, web services and maintained/tuned system infrastructures. David’s goal now is to further the use of continuous improvement practices where needed and to improve the continuing adoption and security of enterprise cloud-hosted infrastructure.

His IT career has spanned over 3 decades, and he has been exposed to broad business verticals or subject domains. He has worked on the engineering of nuclear submarines and has been responsible for the development of financial web service operations for a major bank. David leads his team or development staff by example. He gets it done. He has recently acquired the MuleSoft Certified Developer – Integration and API Associate license.