Rohit Sethi
by on
Categories: Misc

I wrote this post for our internal team and some of my colleagues suggested that it might be useful to others. It’s a bit of a departure from our normal appsec posts. Let us know if you find it useful!

Background

New employees at Security Compass often feel overwhelmed by the sheer number of things they could be working on at any one time. We have an intentionally flat organizational structure, which comes with some downsides. It means nobody is managing your work queue and telling you what you should work on at any time. It’s up to you to manage your own schedule. This article describes a system used by many people at Security Compass to effectively manage time, reduce stress and get things done. It’s a modified & abridged version of a system documented by David Allen: see his book here. You should really read the book. However, you’re probably here because you don’t have time to read a book.

What is & Why practice Getting Things Done (GTD)

GTD is a system of time management that uses context-specific lists to manage your tasks. It was originally made for busy executives and based on the premise that you have too many things to do at one time to keep in your head. Think about it: what are all things you need and/or want to do? Not just at work, but for anyone / anywhere. If you’re like most people, it will take you hours to just list out everything you need to do. File TPS reports, do your time entries, work on a research project about Node.JS security, register to vote, pay for your parking ticket, write a blog post, sign up for the gym, book a vacation to South Africa, beat your colleague at Foosball, etc. It’s probably the things you aren’t doing that are causing you the most stress. Moreover, that stress makes you less effective at what you’re doing right now because you’re constanty worried about all those other tasks.

Many of us think, “I just need to try harder to remember all the things I need to do” and we rely on our memory to store and process all of these tasks. The problem, as you probably know, is that most people lack the capabllity to remember more than a few things at a time. We forget things, which will in turn causes us to be even more stressed.

We often rely on email to externalize our memory. Our inbox becomes a database of things to do, often with red flags and deadlines to help us prioritize. The problem is that that inbox gets crowded quickly, and soon those red flags and deadlines stop meaning anything. Moreoever, everytime we fail to meet a deadline we lose faith in this email prioriitization system and it stops becoming an effective time management technique.

This article will descirbe *some* of the salient points of GTD and how to practically implement them, as interpreted and modified by yours truly. You will likely modify/tweak these techniques to suit your tastes & style. No matter how you implement it, effectively using GTD will reduce your stress and make you more effective in your work. It will give you a system you can rely on, provided you make an effort to actually practice it.

Step 1: Write Everything Down

Write every single thing you need and want to do down on a single list. I mean everything. Do you have a burning desire to learn crochet in the back of your head? Write it down. From this moment on, everything you ever need to do – apart from routine, everyday tasks that you don’t need reminders for – will be written down.

If you are a geek like me, you’ll want to write this down in some electronic format. I really like using Google Tasks, which is part of Gmail. You can also use Outlook Tasks, or any other task management software such as Remember The Milk. It’s a good idea to select something you can access from your phone so that it’s always at your fingertips.

Getting tasks in Gmail:

1

 

List of tasks in Gmail:

2

Step 2: Sort It All

Look at all the things you wrote down and sort them into the following categories. Note, if you are using Google Tasks then you can do this by creating a new list for each category:

 

3

 

Next Action

 

This is something that you need to work on, and will take less than an hour to complete. You’re not waiting on anyone else to do this thing and it’s not a Project (see below). Example: “File TPS report”. A very critical point to keep in mind is that there is concept of “priority” here – everything in next action is important and must be done.

Waiting For

 

This is something that you are waiting for/ blocking on somebody else to do before you can work on it. You want to have these stored somewhere so that you can occasionally follow-up. Example, “Select dates for vacation” if you are waiting for your friends to tell you when they are free to go to vacation.

Projects

 

A GTD project is different from your normal idea of a project. A project, in this context, is any “big” task that might take many hours, days or weeks to complete. Example, “Work on a research project for Node.JS security”. This should basically be anything that’s too big to put in the “Next Action” list.

Specific Date

 

This is something you don’t have to start until a specific date. Example, “Register to vote” 2 months before the next federal election. You should be able to use some sort of reminder mechanism in your software to remind you on that date. In Google Tasks you can do this by clicking on the task and hitting “shift + enter” and setting a Date. Once you hit that date, you should convert that task to Next Action. Remember, the specific date is a start date and not a due date.

Some Day / Maybe

 

Things that you would like to do if you had spare time. It may hard to believe right now, but at some point in your life you will have spare time and may actually make progress on these things. Example, “Learn crochet”.

 

Some people elect to create additional lists for different contexts. For example, “Next Action – Work” which is different than “Next Action – Home”. Some people use a category called “To Read” which you can focus on when you have long periods without internet connectivity, such as on a plane.

Do not put deadlines on anything. You can generally be aware of deadlines, but recognize that your list of Next Actions will shift constantly and any sort of deadline you add will soon become a suggestion rather than an actual date you abide by.

Step 3: Inbox Zero

 

Now go and do the same thing with your inbox. Create sub-folders in your inbox for the above categories and FILE EVERYTHING. Delete the email you don’t need. Create another sub-folder called “Reference” for emails and file anything that you don’t need to specifically action on but you want to keep for reference there. You may already have a system for keeping emails archived, in which case you can just use that pre-existing system.

From now on your inbox is only for reading and processing new messages. If you have to do something for it, and it takes less than 5 minutes, then just do it. Otherwise, add it to Next Action or Projects respectively. Clean out inbox regularly and do your best to keep it to 0 messages.

By this point you *should* start to feel some sort of euphoria. Everything you need to do is categorized and externalized. You no longer have to over-burden your brain. If you can keep up with this system you should feel a permanent reduction in stress.

 

Step 4: Project Plan

 

On a periodic basis, you need to revisit your list of projects. For each project, take some time to distill the project into a set of finite tasks. Then add the next task into your next action list. This will allow you to make incremental progress on a project.

For example, you might break up “Work on a research project for Node.JS security” into the following steps:

•  Review introduction materials on what Node.JS is

•  Setup an environment to start developing with Node.JS

•  Build a “hello world” app with Node.JS

•  Google search on existing material for Node.JS

•  Review OWASP Developers guide against Node.JS feature set

•  Review Node.JS features for prospective security issues

•  Research and try to exploit issues found in previous item

•  Write up draft of research

Each step is a concrete step that you can do along side other work without requiring 2 interrupted weeks of heads-down time to focus.

 

Step 5: Maintain

 

Here’s the hard part. You need to do your utmost to keep this system going. Every new email or task you get needs to enter the system, every time. When you work on a task, you are in a zen state of mind – you are not thinking about other tasks because you have a trusted system that captures every single thing you need to work on.

You *must* frequently check your next action list to see what things you need to work on, but only between working on tasks or when you choose to take a break. Every time you complete a next action, you can file it/ delete it/mark it as complete – whatever you have to do to get it out of the list.

You will periodically review your “waiting for” list to see if you can follow-up with people. You will periodically check your project list and add specific steps to your next action list.

If you can do all of this consistently, I guarantee reduced stress levels and better productivity.

Now go get things done!

 


 

 

 

Appendix A: I Have Too Much To Do!

 

If you go through this process and you wind up with an unwieldy list of next actions, then the system will break down. A next action list only works if you can actually make progress on it.

If you have too many things to do that you aren’t ever making progress on your list of next actions, then I hate to break it to you but you’ve committed to too much. Think hard about that list of actions. For each task, ask if you can put it into of the following buckets:

•  Decline: Can you get away with saying no to whomever expects you to finish this task, or asking them to find somebody else to do it?

•  Delay: It’s hard to admit, but you just don’t have enough time to do even useful things. If possible, move the task to “Specific Date” and give it a date in the future when you will revisit, hopefully when your plate is a little clearer.

•  Demote: Are there certain next actions that really aren’t that important at all? Move these to “Someday maybe”.

•  Delegate: Can you yourself find somebody else to work on this task?

Always remember to prioritize productivity gain tasks/projects. For example, reading the book “Getting Things Done” may seem like an enormous investment of time but it may just yield better productivity for the rest of your life. This is also true for other projects, such as finding a tool to help you do manual work (e.g. an app that scans business cards rather than entering them in yourself).

Guest Blogger
by on

We’re excited about our integration with Fortify.  It follows on our recent Veracode integration.  With these integrations a company can automatically create a set of tailored security requirements and automatically test the requirements. We think it’s a huge boost for application security. It works like this:

Start by modeling your application in SD Elements:

1

Then generate a set of tailored tasks (i.e. requirements) in SD Elements:

2

Use these requirements during development:

 

3

Run the application through Fortify and import the scanning results:

 

4

 

Review the verification status of requirements in SD Elements:

 

5

You now know:

  • Which requirements have failed verification (i.e. a vulnerability was discovered)
  • Which requirements have passed verification (i.e. a vulnerability was not discovered, and Fortify can generally find this kind of vulnerability in supported languages / frameworks)
  • Which requirements have partially passed verification (i.e. Fortify can find some but not all instances of a vulnerability)
  • Which requirements were not covered by Fortify. These need to be manually tested

Now use SD Elements test cases to manually test areas not covered by Fortify:

 

6

 

About the Guest Blogger:

Chris_TysonChris Tyson, has recently joined Security Compass as our Customer Success Engineer.

Most recently he was a Senior Sales Engineer at Klocwork. Klocwork’s tools find exploitable security defects, code quality issues, architecture and metrics issues in software.  Previous to that Chris has extensive customer facing experience in Pre-Sales Engineering, Training, Consulting, Customer Support, Software Development and management of software development teams.  He is passionate about security, software quality and user experience. Chris has a Bachelor’s Degree in Computing and Information Science with a minor in Business Administration from the University of Guelph.

 

Our customers consistently tell us that one of the most exciting features of SD Elements is the capacity to integrate security and compliance requirements with leading Application Lifecycle Management (ALM) tools like Atlassian’s JIRA. The process is simple:

 

1. A project manager (PM) or security architect create an application in SD Elements and answer the questionnaire

 

1

 

2. The PM or architect sets up integration with JIRA

 

2

 

 

3. Developers accept and close the security requirements, just like any other ticket

 

3

 

4. SD Elements detects when the tickets are closed in JIRA and marks the tasks as DONE in SD Elements

 

4

 

5. A scanning tool or human tester validates that the requirements have been met.  Alternatively, developers build test scripts to automatically validate the requirement.

 

5

 

Security practitioners can see that security has been added in, and developers use JIRA or any of the other supported ALM tools without disrupting their current process. Another important benefit is that once connected, the development team can get a continuous stream of new security and compliance requirements embedded right into JIRA. This works particularly well with agile and continuous integration environments where up-front planning for security requirements isn’t readily available.   This narrated video illustrates that integration in action.   Interested in giving it a shot for yourself? Contact us to learn more.  

 

 

About the Guest Blogger:

Chris Tyson, has recently joined Security Compass as our Customer Success Engineer.

Most recently he was a Senior Sales Engineer at Klocwork. Klocwork’s tools find exploitable security defects, code quality issues, architecture and metrics issues in software.  Previous to that Chris has extensive customer facing experience in Pre-Sales Engineering, Training, Consulting, Customer Support, Software Development and management of software development teams.  He is passionate about security, software quality and user experience. Chris has a Bachelor’s Degree in Computing and Information Science with a minor in Business Administration from the University of Guelph.

Rohit Sethi
by on

At the surface, the answer to this question is clearly no. Development teams that build more features and spend less time on non-functional concerns will ship software faster. This comes with a host of short-term business benefits including more first-mover advantage, seemingly decreased development costs, and faster feedback loops for iterative development. It stands to reason that people who decide on software development scheduling are more likely to favor spending as little as possible on non-functional areas like security.

This reasoning is flawed.

Applications that store, process or transmit credit card data, protected health information, financial data, various kinds of data for government and/or defense, and other regulated industries are often required to perform a certain level of due diligence prior to releasing an application into production. The simplest way to meet these requirements is to perform a manual or automated code review or penetration test at the end of the assessment, which is what most organizations end up doing. If you are mandated to fix these vulnerabilities prior to deploying to production, you are spending anywhere from 90 to over 400 times the cost of having prevented that same defect with adequate requirements. That additional cost generally manifests itself in one of two ways: cutting back on other features in favor of fixing defects, or delaying the release. Bottom line: ignoring security to develop faster works against the goal of faster-time-to-market as soon as security becomes mandatory. You can achieve faster time to market by agreeing on the right kind of security requirements according to your organization’s risk appetite.

Most applications aren’t mandated to specifically employ application security by regulation. Yet even these applications may not be off the hook. Recent rulings by the Federal Trade Commission (FTC) may leave you liable if you do not adequately protect your customer’s data. Moreover, internal auditors assessing operational risk may mandate security testing as part of internal controls program based on standards like ISO 27001. Even in the absence of mandatory testing, simply ignoring application security can cost you millions in the event of a breach. With web application insecurity being a leading cause of these breaches, many organizations employ application security practices as a form of insurance. These organizations have a choice once they detect a vulnerability: fix it now and risk a delay in release date or deploy into production without a fix. Many opt for the latter, but do so without a conscious cost/benefit analysis of building for fixing defects on user-facing features vs. fixing a potential security vulnerability. The business benefit of working on a feature is often incremental revenue gains or operational efficiency, whereas the risk of not fixing a serious security vulnerability is not only the potentially massive direct costs of a breach but also the brand liability of having inadequately protected customer data and potential increased scrunity by regulators like the FTC. Thus, overtime, organizations often favor fixing security vulnerabilities prior to releasing in production – and that inevitably impairs the coveted time to market.

Software security requirements allow you to know which risks you are wiling to take ahead of time and prevent the ones you are unwilling to accept. This is true even for legacy applications that undergo changes or have to keep up with emerging security weaknesses. Addressing security requirements while building software is substantially faster than fixing security vulnerabilities later, and since so many organizations end up mandating fixing security defects, preventing those defects up-front yields faster time-to-market.

Let’s say you’ve just had a pen test or security scan performed on your application. You review the list of findings and get to work on remediation. Apart from obvious shortcomings of any individual single assessment technique, you may also be doing a disservice to meeting your business goals. Here’s why:

The goal of your assessment is likely to understand open risks in your application with the goal of remediating or otherwise compensating for those risks. In most cases you only have a limited amount of developer time to fix security issues as they try to juggle building business value with new features. The problem is that by focusing remediation efforts on what a scanner or pen test finds, you are monopolizing precious developer time to fix the issues that technique can find rather than the risks that actually matter to your business.

For example, suppose your scanner identified Missing HttpOnly cookie flag as a finding.   At the same time, your scanner was unable to find the kind of basic authorization flaws that grab international headlines, such as the ‘delete any photo on Facebook’ bug that a researcher found last week. By focusing on the scanner result, you may be spending precious developer time on the cookie flag even though the authorization issue is a much bigger risk to your organization.

A more sensible approach is to start with identifying the risks that you care about, either through automated security requirements analysis, threat modeling, or some other technique. With risks identified, you determine which of those risks your assessment technique is capable of finding and which ones it can’t find. Use other techniques to assess the gaps, either by manual testing/code review or – if resources are tight – just asking developers if they do things like perform authorization checks on all API calls. As we’ve said before, coming up with a list of risks you care about doesn’t prevent you from looking for other kinds of vulnerabilities. It does, however, allow you to focus your efforts on the risks which can be harmful to your business since 78% of real incidents are easily preventable.

 

one-sized fits all approach to Software Development Life Cycle (SDLC) security doesn’t work. Practitioners often find that development teams all have different processes – many seem they are special snowflakes, rejecting a single SDLC security program. This may not be much comfort to somebody who needs to lead a SDLC Security initiative across a large organization – but in our experience it is possible to build a program of application security that works for different development teams by recognizing that each SDLC tends to fall into one of three patterns: Waterfall, Agile and Continuous Development/No Process. Your secure SDLC initiative should provide a toolkit that works for each without severely impacting the developers’ productivity. Our whitepaper presents detailed guidance on how to embed security requirements into each.

Characteristics of the Three Patterns for SDLC Security:

1. Waterfall: Development with big upfront design.

  • Managed by a central person or team of Project Managers (PMs).
  • May be iterative, but generally has long release cycles (i.e. quarterly, bi-annual or annual releases).
  • Common in highly regulated industries, large enterprises, and software vendors who create expensive to patch software (e.g. shipped software, embedded devices).

2. Agile: Iterative development

  • No formal project management as compared to waterfall. Scrum masters are responsible for watching over process while product owners are responsible for setting priorities.
  • Each release results in shippable software – typically 1-4 week releases.
  • This tends to be the most popular style for internal applications, mobile applications, and increasingly external-facing web-based applications. In general, we see agile as the most common pattern of development for new software.

3. Continuous development/no process: Either hyper-optimized with automation, leveraging continuous integration tools like Jenkins configuration management systems OR absolutely no development process or standardized tooling, such as Application Lifecycle Management (ALM) tools. Both styles impact security requirements as such:

  • Releases and even iterations are completely removed from the picture – software is in a continuous state of release, with no chance to embed security ahead of time.
  • Absolute minimization of process overhead.
  • Cost of a defect is low, since it’s relatively easy to deploy a fix.
  • Continuous development is very popular with eCommerce companies and other Internet-based businesses.

Each style tends to have different needs from a secure SDLC standpoint:

 1. Waterfall

  • Willingness to spend-time up-front to “do it right” – if and only if the business thinks security is a priority.
  • With sufficient buy in, design-time analysis such as threat modeling, and longer cycles on security activities such as a full-scale code review are conducted.
  • Can accommodate several different security assessment techniques.
  • Cost of fixing a security vulnerability can be extreme, the window of risk exposure can be particularly long if it involves end users patching their systems

2. Agile:

  • Primarily feature driven, particularly when adopting user stories as the primary method for conveying requirements.
  • Typically do not have any process around managing non-functional requirements
  • Can adopt security into iteration planning process by baking security requirements into product backlog.
  • Emphasis on automated testing, whenever possible – may be able to accommodate manual testing from QA or security teams.
  • Cost of fixing security vulnerabilities/window of risk is lower than waterfall, but there is still an emphasis of shipping defect-free software.

3. Continuous development / no process:

  • Obsessed with automation and protecting developers from process overhead. Anything that requires developers to take time away from coding is often met with fierce resistance.
  • No ability to plan up-front except on a per-feature or per-change basis.
  • Often willing to invest in building security features into frameworks, automated front-end tools to shield them from developers.

Recognizing the three patterns and providing toolkits that work for each can dramatically lower the resistance for a SDLC security initiative. Read our guide on how to embed requirements into each.

Also see:

 

 

To keep an unbiased perspective when evaluating a software or service, it is best to have the important criteria ready beforehand. This will ensure that during the evaluation period, you can keep an eye on the key factors that are important to you, and provides you an easier way to make decisions commensurate with your goals.

We have looked at what questions enterprise organizations had when evaluating secure application lifecycle management solutions and put together a guide of evaluation criteria below. The list might be overwhelming, so we encourage you to pick the more items that align with your goals so that you choose solution that’s right for you.

 

Evaluation Criteria

  1. How can the tool help to automate and streamline the secure software development life cycle process?
  2. How does the tool automate and improve our ability to gather and track application security requirements?
  3. Can the tool be used to improve analysis time for security fixes and other incoming requests reducing the number of man hours spent on false positives?
  4. Does the tool provide security guidance and links to reference material to application teams?
  5. Does the tool provide auditability of user actions?
  6. Does the tool have the ability to export requirements to other systems such as Issue Tracking tools and other Application Lifecycle Management (ALM) solutions?
  7. Does the tool provide for multiple user level privileges and permissions (i.e. admin/user read only)?
  8. Is the content periodically updated with the latest security requirements by the vendor?
  9. How long does it take on average to model an application and compile a threat report and/or get a requirements list?
  10. How long does it take on average to model a new release of a previously modeled application?
  11. How does the process and the tool used for it benefit each of the following roles by improving either performance, by saving time, or by other means?
    • Developers
    • Project Lead / Project Manager / Architect
    • QA / Testers
    • IT and Application Security experts
    • Product and Project Managers
    • Security Managers
  12. What is the estimated Return On Investment (ROI)?
  13. Is data transmitted to the application over a secure channel?
  14. For the SaaS (software as service) model, is the tool accessible 24/7 (except for standard maintenance)?
  15. Does the tool vendor have controls in place to keep the data secure?
  16. How easy is the tool to use? Do new users need significant training to understand the application or is it intuitive?
  17. Is the tool useful for people with different degrees of security expertise?
  18. Has the tool been successfully deployed and adopted in other complex environments?
  19. Do other customers have positive feedback about using the tool?
  20. Does the tool help build-in and track compliance to relevant regulations / legislations?
  21. Can we add custom content to match our needs?
  22. Can we modify vendor-supplied content?

Heading into an evaluation with defined criteria will allow you to remain objective and keep an eye on the factors that are critical to your success.

Rohit Sethi
by on
Categories: Partners

This is a guest blog post by Christian Pedersen, CTO and co-founder of SD Elements partner OneLogin.

One of the exciting things about being the CTO of OneLogin is that I’m constantly learning about fantastic cloud applications to boost IT performance and security. There are now cloud applications for IT teams of every size and focus.

For example, in the world of software development, there are now cloud-based apps to help build security into your app from day one. Take SD Elements, which is kind of like tax planning software for application security: you describe the technology stack, features and compliance requirements of your system and SD Elements presents you with  a series of tailored, prescriptive requirements.

Like many software companies, we rely on the Agile Project Management methodology. Agile is great, but sometimes there are challenges stemming from ‘islands of activities’ and that’s where a cloud-based work and project management solution like Clarizen helps get everyone on the same page. Clarizen centralizes all of your release backlog data, task updates, bugs, documents and communications into a single system.

Once your app goes live, New Relic is the killer app for preventing downtime due to application errors. New Relic helps you make sense of the noise by allowing you to monitor the metrics that really matter. For example, you can quickly identify application errors, fix the underlying problem, and improve your mean time to resolution (MTTR).

For those IT departments juggling dozens of applications and resources, Innotas provides an integrated platform for both Project Portfolio Management (PPM) and Application Portfolio Management (APM).  With so many projects competing for resources, Innotas gives you that holistic view so you can prioritize projects, optimize shared resources, govern core processes, and ensure alignment across your entire IT landscape.

And when things go wrong or end-users need help with a new service they often end up at the IT help desk. That’s where BMC Remedyforce can be a real life saver. Remedyforce is a comprehensive IT service management solution built on the force.com platform. It helps you connect with customers to provide fast, accurate services in a way that optimizes IT efficiency. Of course, with so many services moving to the cloud, many help desks find themselves burdened with password-related tickets, and that’s where OneLogin comes in.

OneLogin reduces password sprawl, and automates password resets and user management so you can free up IT resources for higher value activities. Of course, when it’s time to off board members of your team, it’s important to make sure your sensitive IT and project data remains within your company. OneLogin’s real-time Active Directory and LDAP integration acts as an effective “kill switch” for when IT team members move on.

Rohit Sethi
by on
Categories: Our company

We’re looking to hire great developers. We know you have your choice of employers, and I’d like to explain why being an SD Elements developer may be the right match for you. If you’re unfamiliar with us, SD Elements is a product of Security Compass. It’s a security requirements solution that helps development teams build security into their software from the start. You can learn more about us from our website: www.sdelements.com.  You can see some of our open source code such as integration plugins here: https://github.com/sdelements.

We’re not a venture-backed company. We’re boot-strapped, which means all of our money comes from selling products and services to customers rather than outside investors.

We offer our employees the ability to have a meaningful impact on the world. We believe it’s a fantastic time to be in technology, but insecure software threatens to dampen innovation. Major advances in fields like healthcare and utilities can greatly improve our lives, but not if those advances leave us vulnerable. So many of the security incidents we hear about can be traced back to insecure software: vulnerable web applications, malware exploiting vulnerabilities in desktop applications, and software with flaws on network devices and operating systems. Despite over a decade of best practices and tools to improve the security of software, there are still too many incidents because of known, preventable defects like dynamic SQL and use of insecure string operations.

We want to change that. While it’s no silver bullet, we believe security requirements will make a big difference and SD Elements is leading the way here. We’re not alone. Our clients range from large technology companies and global financial institutions, to medical technology companies, utilities, telecom, media, public sector and transportation companies. Last year we grew over 300% and we’re on track to continue that growth rate. It’s an exciting time to be here and we want you to be part of that excitement. Apart from the exciting growth and opportunity to really have an impact on improving the state of security, there are other reasons you may want to work here:

  • Developers work with an incredibly talented group of people. I am fortunate and humbled to work with people who are much smarter than I am. There is something exhilarating about being part of a group of people who could collectively solve almost any problem. The chance to work with them is, in my opinion, the most rewarding part of the job.
  • Customer satisfaction is paramount. Everyone is focused on goal #1, which is to super-please our customers. We know finances are important, but we really believe that ecstatic customers eventually lead to all other goals including revenue growth. Because we are boot-strapped, we can devote all our attention to customers and not investor requirements.
  • We don’t believe in top-down management for software development. While there is some organizational structure in the company, we think the people closest to the ground make the best decisions. Decisions are either made in groups or by the person most qualified to make the decision. Although you may not always get your way I can promise your opinion will always be heard and respected.
  • The role of management is to coach, listen, and be compassionate. We sit with team members individually to find out what the company as a whole can be doing better, and how we can reduce impediments to getting work done. In addition, we believe in transparency throughout our operations. We have an open-door policy at our meetings: You have the ability to get involved with any part of the business that you find interesting.
  • Team members have flexibility in their schedules. While we ask that everyone comes into the office three days a week to help build a strong team dynamic, nobody monitors when people come into or leave the office. We are only concerned with consistently delivering value to customers.
  • Developers have 10% time, which means spending one day every two weeks on a project that helps you learn. We actively encourage open source development during 10% time, and our developers have used the time to build awesome tools like Let’s Chat . In addition, we have a monthly hackathon where developers work together to build up tools that improve our work. These times give developers a chance to learn about new technologies that they find interesting and that can enhance their careers.
  • We believe in writing good software. Every commit has testing coverage, followings coding guidelines, and is peer reviewed. We understand what technical debt is and take it seriously. As you might expect, we take software security more seriously than most development teams and regularly eat our own dog food by using SD Elements as part of our development process. Since everyone in management has a development background, we understand the value of good software engineering practices and we don’t believe in recklessly building unmaintainable software.
  • We are focused on fixing and solving, not pointing fingers. We believe that blaming people leads to risk aversion, a CYA-attitude, and a culture that breeds politics. Team members feel safe in admitting to mistakes, because they know our focus is on learning from those mistakes rather than penalizing people for them.

Because we’re boot-strapped, we can’t yet offer some of the office perks you’ve come to expect from venture-backed start-ups, like free dry-cleaning, daily catered lunches, or unlimited yoga classes. If you’re judging a workplace primarily by its office perks, this isn’t the right job for you. If, on the other hand, our values speak to you, then drop us a line at careers@sdelements.com. Anyone can make claims about their corporate values, so I invite you to ask any of our current employees about their candid opinion as part of the interview process.

Rohit Sethi
by on
Categories: Building security in

When we ask security contacts at our enterprise clients “What software development methodology does your company use?”, they usually pause for a moment and answer “Everything”. Individual development teams tend to adopt processes that work best for them. Heterogeneous development processes wreak havoc on plans for adopting enterprise-wide secure SDLC efforts. There are at least three reasons why development teams within the same company have different development styles, including:

  • Business needs: Large companies are often composed of units in different kinds of business. For example, a large media conglomerate could have Internet providers, movie studios, and a retail store division. The customers, employees and supply chain of each business unit also differ, often impacting the way software is developed or procured. Developers at the brokerage department of a bank might work at warp speed to get incremental improvements on trading times, whereas the retail group might be very careful about the pace of change
  • Growth through acquisition: Many corporate acquisitions include the acquired company’s software and development teams. Each company likely had a different corporate culture that impacted the way their respective teams worked. For example, a small start-up software shop may value developer autonomy and lack of process while a larger software vendor may value risk management and accountability. The former may lean towards a self-organized team without formal project management while the latter may have a central Project Management Office (PMO)
  • Software type: Teams that ship software on embedded devices are often very careful about requirements analysis because the cost of shipping an update is sky-high. On the other hand, teams that build eCommerce web portals may deploy hundreds of changes every day and spend very little time in requirements planning

Security practitioners should keep this in mind when designing a secure SDLC effort. Forcing a security process on development teams that doesn’t take into account the way they develop software is a recipe for disaster. A good goal to have for secure SDLC is to minimize the impact on the team’s existing software development practice, which may mean investing more time up front to give development teams options on how to bake security in a way that works for them.