-
Notifications
You must be signed in to change notification settings - Fork 0
/
sec-consider-and-lifestyle-exchange.html
101 lines (96 loc) · 7.13 KB
/
sec-consider-and-lifestyle-exchange.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
---
layout: post
cover: 'assets/images/cover13.jpg'
title: "Security Consideration and Lifestyle Exchange (SCALE)"
date: 2016-06-25 11:01:00
tags: content
subclass: 'post tag-content'
categories: 'dlwhitehurst'
navigation: True
logo: 'assets/images/favicon.png'
---
<h3>Introduction</h3>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h3>Urgency</h3>
<p>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.
</p>
<p>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.
</p>
<h3>Culture</h3>
<p>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?
</p>
<p>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.
</p>
<h3>Proposal</h3>
<p>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.
</p>
<p>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.
</p>
<p>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.
</p>
<h3>Conclusion</h3>
<p>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.
</p>