The DevSecOps Mindset: We Are Not Alone

I’m not going to argue about why “Security is Everyone’s Role” – we’ve already agreed that it is, and there is no point in continuing that discussion. Instead, I’ll try to explain how DevSecOps has been influenced by that mindset – and should also be everyone’s business.


Picture is from:

A Long Bit of History in Two Minutes

In the beginning there were mainframe-based batch processing applications created by Dev and Ops supporting big computers, but not apps

Then, light was seen coming from alphanumeric terminals that supported a client server architecture. App specific Ops was born somewhere around this time. Information security — at least the way how we know it today — was still nowhere close.

Then God DARPA said, “let there be Internet, be fruitful, and multiply, and replenish the earth with the streams of useful information available to everyone”. We all saw that it was all good, until we noticed one bad thing about it. There were bad guys trying to get access to information that they were not supposed to see. This is when information security was born.

At that time security has been completely separated from Dev and Ops. It was not embedded within any SDLC process. Newly created InfoSec companies were coming in to pen test systems and generate long PDF reports with findings and remediation suggestions. Security was a self-sufficient, black box kind of thing that didn’t care much about how those PDF reports would be used.

Meanwhile, business wanted software development practices to move faster, and Dev responded with Agile methodologies (but completely forgot about Ops, which was deeply rooted to the way new apps and systems were created at that time). It then became obvious that making Ops the part of this process was a must, and this is how DevOps was born.

All of that was good, but very soon everyone has realised that if security remained isolated, there was not much the DevOps movement could do to achieve the business goals mentioned above. Next, the DevSecOps term was coined.  (I could find the first use of it in a tweet published on 03/09/2012).

We Are Not Alone

The major question here is: have we included all necessary parties this time? An obvious answer coming from the title of this article is: of course not.

The thing is, while DevSecOps or DevOps concepts could be sufficient for small companies and startups, where any employee belongs to one Dev, Sec or Ops category — for bigger, well-established and heavily regulated companies, it’s never the case.

There are many other parties involved: e.g. risk, legal, compliance,  governance, change control (yes, it still exists), etc. Believe it or not, all of them are part of a software development process. I can recall a case when in the middle of Dev process engineers were asking attorneys questions like: “what will happen if we allow users on our system without asking them to agree with our terms”, or “how will this new feature impact our risk and compliance posture”.

Please note that in situations like these, risk, compliance, and legal pros become a part of the software development process.  And if a team runs in agile mode, these three groups don’t have the luxury to research a risk, compliance or legal issue for a month or two. They need to provide an answer fast to make sure that Dev, Sec, Ops meet their sprint deadlines.

If you think about all that, you will probably agree that in big organizations DevSecOps is really DevSecOps plus almost everybody else.

We’ve started with Dev, then realized soon that Ops and Sec should be included as well.  Now, let us think about how everybody else could be included to the process. It’s not only about integrating automation throughout development, deployment and security, it’s also about big changes in processes.  It is also about the way different — and not necessary technical organizations — are involved within a software development life cycle and their ability to respond fast to the needs of all other parties involved.

I think, the next big thing, which is coming after DevSecOps is DevSecOpsAndEverybodyElse.

Either do that in your organization, or admit that you can’t keep pace with the speed required by business (and that you are a show stopper party pooper).

Finally, I encourage you to read this year’s full set of responses from the 2018 DevSecOps Community Survey here.  The results are fascinating.

Google Auth 2FA TOTP Client for Samsung Gear, Android, Android Wear, Fitbit


An idea was to have a Google Auth/2FA TOTP Client running on all Android-bound phones and watches. It includes:

  • Contemporary high end Android phones running ver 6.0 or higher
  • Contemporary Samsung Gear devices such as Gear S2, S3, Sport, Galaxy
  • Android Wear watches
  • Fitbit Versa and Ionic watches

The major benefit is that it integrates phone’s, Wear and Gear’s 2FA apps in a single solution and allows transferring accounts between peers in any direction: from phone to watch or vise versa. There is no need for Google’s stock app anymore, because the companion includes all GA functionality and adds features that stock GA app is currently missing.

The companion allows scanning Google’s QR bar code, which is a client/server shared secret used for generating one time passwords (OTP).

In addition, the Android’s companion can be also used to backup and restore all 2FA accounts. Backups could be encrypted using a password based encryption (PBE) with HMAC signature intended for verifying  backup’s integrity (e.g. signature verification will fail if a password is not valid).

Plain backups are also supported, but not recommended, since they are stored in Android’s “Download” directory that can be accessed by other applications that are granted “read storage” permission.

Using Google Drive for backup/restore operations makes syncing accounts across all your Android, Gear and Wear devices simple.

Where and How to Start

To create a 2FA account on your phone using this app, you’ll need a shared secret, which is a Base32 code generated by your 2FA provider. How to get that code depends on a provider and the code is generated at the time when you enable 2FA in your web app. Instructions for getting the code for all Google accounts are provided here:

However, those instructions change often, so the best way is to read recent 2FA enabling instructions for each provider. The app was tested and actively used with the following 2FA providers:

  • Amazon
  • Google
  • WordPress
  • Twitter
  • Fastcomet
  • DHS
  • Sonic Internet Provider

The number of websites supporting 2FA grows fast and the list above will grow as well. Check also this to learn what other websites support TOTP: websites supporting 2FA

App Flavors and Their Usage

How to Choose Right App in Google Play Store

There are two apps in Google’s Play store and the simple guidance below will help you to make the right choice.

  1. “GAC – 2FA TOTP Auth Client ” supports Samsung’s Gear and Android Phone. Choose this one if you want to have an authenticator that works as a standalone app on an Android phone, or if you want an Android phone and Gear app to work together. The Android app is free,
  2. “GACW – 2FA TOTP Auth Client for Wear” is very similar to the first one, except that in addition to Gear, it supports Android Wear and Fitbit devices as well. It also doesn’t have any ads. Choose this one if you need support for both Gear and Wear or Fitbit devices, don’t like ads, and don’t mind to spend $2.

How to Choose Right App in Samsung Store

There are three GAC apps in Samsung’s App store, and the guidance below will help you to to select the right one:

1. First Client for 2FA TOTP Google Authenticator without Android’s companion was created in 2015, supports many legacy devices such as Gear, Gear 2, Gear Neo, and Gear S, along with newer Gear S2, Gear S3, and Gear Sport. Buy this application only is you need support for legacy devices. If you have S2, S3 or Gear Sport, consider other two choices.

NOTE: This app has been decommissioned since 11/9/2019 due very low demand and confusion coming from not reading instructions.

2. Client for 2FA TOTP Google Authenticator with Companion was created in 2017, supports Gear S2, S3 and Sport only, and requires Android’s companion to work. Use this app if you have S2, S3, Sport, or Galaxy and like additional Android’s companion features such as bar code scanning and backups, and don’t need support for Android’s Wear and Fitbit devices.

3. “GACW – 2FA TOTP Google Auth Client for Gear, Wear, Android” was created in 2018, has the same functionality as “Client for Google Authenticator with Companion”, but in addition, it also supports Android’s Wear devices. Use this app if you have Gear S2, S3, Sport or Galaxy, and need support for Android Wear or Fitbit watches as well. It’s free in Samsung store, but GACW companion will cost you $2 in Play Store, so in the end the price is the same as for other two.


Supported Phones

  • All Android Phones with Android version 6 and higher should be supported
  • iPhones are not supported and there is no plans to support it in the future

Supported Smartwatches

The following Gear devices are supported:

  1. Gear S2
  2. Gear S3
  3. Gear Sport
  4. Galaxy

The following Fitbit devices are supported:

  1. Ionic
  2. Versa

Theoretically, all Android Wear devices should be supported by GACW as well. Since there are too many of different models in this category, we were not able to test all of them, so if you see any problem with your specific Wear watch model, please provide device details to us and we’ll try to fix.

The minimum Android version to run the companion app is Android 6.0


  1. Android application can be downloaded from Play Store: GAC or GACW
  2. The most universal way of installing GAC application on Gear device is through Samsung’s Android Gear App: Gear App. To install GACW on your Wear watch, use Android’d Wear OS app.
  3. If you browsing apps from a Samsung’s Galaxy device, you can also try a direct link for GAC, but it doesn’t work in all browsers even on Galaxy devices:

Available on Samsung Galaxy Apps

Refunds, Reviews, Donations

Please check Google’s Play Store and Samsung Galaxy App Store refund policies before purchasing any paid app. Please also notice that Google and Samsung usually charge taxes and marketplace maintenance fees that only they can refund, so contacting them for a refund is your best option.

Samsung app store refund policies:

Google play store refund policies:


If you submit a review, especially negative one, please provide as many details as you can, so we can review and help. We’ve seen quite a few responses without any details, and helping in those cases is difficult. Please also read this wiki for a quick start.

You can provide the details either in this wiki’s comments, or send a direct email to the admin whose email address can be found in the app’s description.

Expenses for supporting various Android and smartwatches apps are much bigger than income generated by app stores so far. Real smartwatches are often required to test apps on new models. Software emulators, especially Samsung’s ones are not very good, and do not reflect the real “look and feel”


If you like this project and want to see more features and other smartwatches models supported, have your own suggestions that you want us to consider, please donate to the project using the bitcoin donation box below.

  • Bitcoin
Scan to Donate Bitcoin to 1CRMQd91Lhm2EP8vSXcyyP2FsTfXXpAjF4

Donate Bitcoin to this address

Scan the QR code or copy the address below into your wallet to send some Bitcoin

Why Updating Old App Not Possible in Samsung Store

The old GAC app supports many legacy Gear devices such as Gear, Gear II, Gear Neo, and Gear S. Since all these devices are different, they require different binaries. Samsung App Store doesn’t allow mixing companion and non-companion binary types in a single app’s distribution. That’s why new app is needed to enable companion functionality. We will gladly merge versions as soon as Samsung changes their policies (the best scenario) or when we decide to stop supporting legacy devices.

Below is an error message, which is caused by an attempt to add a companion-based binary to the old non-companion style app

Adding New Account from Android on Gear or Galaxy

To add a new account from the phone you’ll need to select “Connect to Phone” menu on Gear first:

Pic 1. Menu Page on Gear

If the device is already paired with and connected to the phone through Bluetooth, an icon on the top will turn green and you’ll see the following message:

Pic 2. Gear Connected to Phone

At this point an account page should popup on the phone automatically. You can either select an existing account or tap “+” button to add a new one. Selecting ‘+’ button will bring you to Scanner page. Now you can point the phone’s camera to a QR bar code. When QR bar code is recognized, the blue border will be blinking and a scanned code will show up in an edit box located just above the camera window.

Pic 3. QR Scanner Page

Press “Send to Watch” button and the scanned account will be sent to your Gear device. You can also save the account to phone by pressing “Save” button. After an account is saved, the “Accounts” page will be displayed. Alternatively, you can get there by pressing an “Accounts” menu in the toolbar.

Pic 4. Accounts Page

At the “Accounts” page you could see a list of OTP tokens for all your accounts, and you can use the buttons on the bottom to perform the following actions (left to right):

  • Send selected accounts to Gear
  • Save all accounts to a backup file
  • Delete selected accounts from your phone
  • Restore all accounts from a backup
  • Add more accounts by either scanning QR bar code or by typing a shared secret manually

Tap a token if you want to zoom it. The token will be refreshed properly in the zoomed view as well. When a color of the border becomes red, a new token will be generated automatically.

Pic 5. Zoomed Token

You can scroll accounts on this page using left and right arrow buttons on the bottom.

Changing Account’s Order

By default the accounts are stored in an alphabetic order, but it’s possible to change the order by long pressing an account name and dragging it to the new place.

Editing Account

Tap an account name in the list to edit it. It will bring you to the Scanner page where you can edit account name, the bar code, or scan the code using the phone’s camera. Press store icon on the bottom to save the account to the phone.

Backing up and Restoring Accounts on Phone

Account restore page can be reached by tapping restore button (second from the right) on Accounts page.

Pic 6. Backup and Restore

By default restore logic will try to create an encrypted backup and password will be required to decrypt the accounts and to verify a signature created by a backup. You can use plain unencrypted backup by unchecking “Encrypt backup” option in Settings, but that option is strongly discouraged. If you want your app to remember the password, use “Remember password” option in Settings.

A button located below “From Watch” title can be used to restore phone’s accounts directly from a watch.

The backups that are not needed anymore can be deleted by selecting them in the backup list and pressing a “trash” button on the bottom.

Saving accounts to a backup file is similar and has two options as well: encrypted and unencrypted backups.

Google Drive can be used to backup and restore accounts as well. Use Google Drive button with a question mark to check what backups are available.

Legacy Backup and Restore

Legacy backup and restore are used to save or restore data in gac-codes.mp3 file that can be used for integrating with an older Gear’s GAC version that doesn’t have an Android’s companion app. Use either MP3 button on the bottom or Legacy Backup/Restore menu items in tool bar to create a backup or restore your accounts from it. The MP3 file will be created in Music directory that can be used by Samsung’s Gear App for transferring it further to your Gear device, where the file can be used to initialize the accounts through “Init from File” menu.

Working with Samsung Watch

Token Page

After accounts have been imported to the watch, they will appear in the main menu. Simply tap an account to see a token. To return to menu again tap a “list” button on the top of token page.


Account Deletion

To delete an account, tap an account name in the list and hold for a couple of seconds until it changes a color and starts buzzing. Confirm account deletion on the following screen:

Getting Help

To get more help on usage tap the “Help” item in the main menu.

Other Screens Seeing on Samsung Watch

When accounts are successfully received by Gear you’ll see the following screen:

Pic 7. Accounts Received from Phone

When messages are sent by Gear to phone, you’ll see the confirmation screen:

Pic 8. Accounts Sent to Phone

If Gear is disconnected from its peer, the green icon will turn red.

Pic 9. No Connection Page


GAC Widget

GAC widget can be used to see the last viewed account and is activated in the same way as any other Gear’s widget: you add it on home screen selecting and tapping the icon below (just swipe screens left until you see it).

Pic. 11 Adding GAC Widget

After widget is added and if a user had recently viewed an account in the GAC app, the latter account will be displayed in the widget. If there was no account previously selected by a user, the following screen will show up.

Pic. 12 Non-initialized Widget

Tap the widget to initialize it or if you want to change a previously selected account. After an account is selected, the widget will display it until another account is selected.

Pic. 13 Initialized Widget

Navigate to the home screen and slide screens left to see the GAC widget.

Adding New Account from Android on Wear

First, start GACW app on Android phone, then start the same on your Wear watch. The beacon icon will turn green on the watch and Wear OS icon will show up in phone’s app tool bar.

Select accounts on your phone and press a “Send to Watch” button or menu item. After accounts are transferred, the Android app is not needed anymore. You’ll see an account list on your Wear device:

Pic. 14 Account list on Wear

Now you can select an account from the list to see the token:

Pic. 14 Auth Token on Wear

Google Auth for Fitbit

IMPORTANT NOTE: Android 9 and higher version do not work with Fitbit Google App anymore due problem described here:

This will be fixed in version 1.1.6, which is pending a Fitbit’s review now and should be available in Fitbit store by the end of February.

Please create accounts manually until this is fixed by Fitbit Android App team. 

Official Link in Fitbit Store

New Features Introduced in ver 1.1.3

The following new features have been implemented in ver. 1.1.3

  • App version is visible in app’s Settings (see General section)
  • App auto-close timeout setting was added. By default it’s off. Edit “Auto close app after n secs” property to setup the timeout in seconds. This can be used to avoid excessive battery usage if app was not closed.

Tested Devices

The following Fitbit devices have been tested:

  • Fitbit Versa (real device)
  • Fitbit Ionic (through simulator only)

Required Fitbit OS SDK

The first app’s version (1.0.5) was built with Fitbit SDK 1.0, which is supported by all known Versa and Ionic devices. However, starting from version 1.0.7 the SDK used was 3.1. It means that for using the latest versions of the app you’ll probably need a firmware upgrade. The minimum firmware version that supports SDK 3.1 on Versa is, for Ionic – Updates are available in Fitbit’s mobile app when you choose your device in the dashboard. Use Settings/About on your Fitbit device to check its firmware version.

If you don’t see the latest app’s version in the Gallery, it’s because your firmware was not upgraded.

Installing Google Auth on Fitbit

Fitbit app is approved and is available in the official Fitbit Store: To find and install it:

  1. Open Fitbit App on Android phone
  2. Tap Apps icon and type “Google Auth” to a search bar

Quick Start

  1. Open Fitbit App on Android and make sure that your Fitbit device is visible
  2. Open GACW App on Android. This step could be optional if you don’t mind typing your accounts manually
  3. Open Google Auth app on Fitbit device

The following screen will popup on Fitbit device:

Pic. 15 No Accounts Screen

4. To quickly check if the app is functional, click top-left button. It will import a testing account from settings:

Pic. 16 Account Received

5. Press green Ok button on the right and you’ll see an account list:

Pic. 17 Account LIst

6. Tap “Test” item to see a token:

Pic. 18 Test Token

7. If everything worked as described above, you can proceed to creating your own accounts. There are two ways of doing this: using GACW Android App and typing accounts manually in Fitbit’s Android App settings.

If you can’t import testing account, most likely you have a connection problem. Read the next section to troubleshoot the connection.

Troubleshooting Connection With the Phone

If buttons on the top do not work it’s certainly a connection issue. To troubleshoot go through the following steps:

  1. Open Android’s Fitbit App
  2. Make sure that Sync is not running. If it does connection from the watch will be ignored.
  3. Select your watch by clicking its name and press “Apps” button. If you see “Unable to Connect” message, you don’t have a connection. Make sure that Bluetooth and Location are on in your telephone settings.
  4. Exit the app on the watch
  5. Start the app on the watch again and check if top-left and top-right buttons work this time

If you tried everything and connection to the phone is still not available, you can always enter the accounts manually in the app’s Settings section from the phone.

Creating Accounts Using GACW Phone App

  1.  Open GACW, Android Fitbit App, Google Auth on Fitbit device
  2. Go to accounts page on Fitbit device and press beacon icon (top-right button)
  3. Device pairing dialogs will show on Fitbit and GACW:

Pic. 19 Pairing

4. Enter PIN from Fitbit to GACW and press enter. If paring is successful, you’ll see a confirmation message

5. Choose Ok button on Fitbit and GACW to close dialogs.

6. Beacon icon should be green on Fitbit’s accounts page. Fitbit icon will show up in GACW’s toolbar and “send to watch” button on the bottom-left will turn green. Select account that you want to transfer and press low left button on GACW to send them to Fitbit. If transfer is successful, you’ll see “accounts received” message on Fitbit.


Pic. 20 Accounts in GACW

7. Tap an account on Fitbit to see a token

Creating Accounts Manually

For each account that you want to create you’ll need:

  • Arbitrary account name, e.g. “Google”;
  • Shared secret in Base32 form.


  1. In Android’s Fitbit App find Google Auth and open its settings:

Pic. 21 Accounts in Fitbit’s Settings

2. Tap “Add Account” link and add a new account in the form: Account:SharedSecret. Make sure that there is no any errors in “Errors” section below.

Pic. 22 Settings Page

Alternatively starting with version 1.1.5

you can add optional parameters after the secret, e.g.



  • 10 is a sequential number of the account in the list (use it if you want to change the order of accounts when they are displayed
  • 1 indicates that HmacSHA256 will be used (default is 0, which is HmacSHA1)
  • 8 length of the token (default is 6)

The full syntax of the account string is as follows:


3. On Fitbit’s device tap left-top button to import accounts from setting. An “accounts received” page will show up if import is successful.

Pic. 23 Accounts Page

Auto Close App

To avoid app running forever and consume battery if a user forgot to exit it by pressing “back” button, auto close feature has been implemented starting from version 1.0.8. The default timeout is set to 0, meaning there is no timeout, but it can be changed in the app Settings page on the phone.

Pic. 23 Auto close app

Known Issues

Issues that have been fixed

Continue reading …

Privacy Policy for Android Applications

Privacy Policy

Oleg Gryb built the GAC Services Android application (hereafter SERVICE ) as a free commercial app. SERVICE is provided by Oleg Gryb at no cost and is intended for use as is.

This page is used to inform website visitors regarding my policies with the collection, use, and
disclosure of Personal Information if anyone decided to use my SERVICE.

If you choose to use my SERVICE, then you agree to the collection and use of information in
relation with this policy. The Personal Information that I collect is used for providing and
improving the SERVICE. I will not use or share your information with anyone except as described
in this Privacy Policy.

Information Collection and Use

For a better experience while using our SERVICE, I may require you to provide us with certain
personally identifiable information, including but not limited to pictures and key used for 2-factor authentication.
The information that I request is retained on your personal devices and is not
collected by me in any way.

The app does use third party services such as Google Play that may collect information used to identify you. This use will is covered by Google Privacy Policies. The author of SERVICE is not associated with Google or its affiliates.

Log Data

I want to inform you that whenever you use my Service, in case of an error in the app I might collect
data and information (through third party products) on your phone called Log Data. This Log Data
may include information such as your devices’s Internet Protocol (“IP”) address, device name,
operating system version, configuration of the app when utilizing SERVICE, the time and date
of your use of the Service, and other statistics.


Cookies are files with small amount of data that is commonly used an anonymous unique identifier and are not use in SERVICE.

Service Providers

I may employ third-party companies and individuals due to the following reasons:

  • To facilitate SERVICE;
  • To provide SERVICE on our behalf;
  • To perform SERVICE-related services; or
  • To assist us in analyzing how SERVICE is used.

I want to inform users of this Service that these third parties have access to your Personal
Information. The reason is to perform the tasks assigned to them on our behalf. However, they
are obligated not to disclose or use the information for any other purpose.


I value your trust in providing us your Personal Information, thus we are striving to use
commercially acceptable means of protecting it. But remember that no method of transmission over
the internet, or method of electronic storage is 100% secure and reliable, and I cannot
guarantee its absolute security.

Links to Other Sites

This Service may contain links to other sites. If you click on a third-party link, you will be
directed to that site. Note that these external sites are not operated by me. Therefore, I
strongly advise you to review the Privacy Policy of these websites. I have no control over, and
assume no responsibility for the content, privacy policies, or practices of any third-party
sites or services.

Children’s Privacy

This Services do not address anyone under the age of 13. I do not knowingly collect personal
identifiable information from children under 13. In the case I discover that a child under 13
has provided me with personal information, I immediately delete this from our servers. If you
are a parent or guardian and you are aware that your child has provided us with personal
information, please contact [me|us] so that [I|we] will be able to do necessary actions.

Changes to This Privacy Policy

I may update our Privacy Policy from time to time. Thus, you are advised to review this page
periodically for any changes. I will notify you of any changes by posting the new Privacy Policy
on this page. These changes are effective immediately, after they are posted on this page.

Contact Us

If you have any questions or suggestions about [my|our] Privacy Policy, do not hesitate to contact


Real Cost of Imaginary Threats


Each time when security folks are asked to evaluate risks, the first thing that they would usually do is to create a threat model. Some don’t like the term “threat model” since it doesn’t really model anything, and suggest another name – “threat analysis”.

After going through many more or less formal threat modelling methodologies, I’ve realized that regardless of chosen methodology, in the end what your customers want is a simple table where threats are described in a plain human language, and a risk score is expressed in simple terms that everyone would intuitively understand, e.g. high, medium, low or HML.

That’s why I prefer calling my threat analysis “threat table”. What can be simpler than that? Anyway, I’m done with choosing “the best threat modelling framework” for today. Threat Table it is.

It’s not really about methodology though. It’s about what you put to that table, and this is where the art begins. No methodology will help you with understanding which threats are real and which ones are speculative or imaginary.

There are many ways to avoid the art component in this process, e.g. you can stick to company’s security and privacy policies, compliance or other regulatory documents and reduce your task to a simple checkbox marking exercise. In this case you are not different from external security auditors whose efficiency is questionable due latest significant security breaches in organizations that formally were considered as “compliant”.

Following company’s policies only can be even less adequate. The policies can be very generic or vise versa – very specific and obsolete because of that (technology evolves fast and so does threat posture).

Then there is a “common knowledge” problem, which is well known and is taught at business schools (I’ve personally learned it here): a fact or opinion known to many, no matter how questionable it is, will always prevail over less known fact or opinion, no matter how valid and important it could be.

Since security is very subjective and speculative, “common knowledge” becomes a bigger issue. In pre-Internet era securing your network and data centers was everything needed to keep external intruders out. There was no such a thing as “connected services” or service oriented architecture. Silos were the most common approach to building absolutely isolated and self-sufficient applications. To avoid inter-application data leak all you needed to do was to segregate networks.

Contemporary applications are built differently. To be competitive and efficient, they need to be exposed not only to other internal networks, but to Internet as well. With that comes absolutely different approach to security: the app should take care of its safety, not the network. Contrary to what many think (here comes “common knowledge” problem again), it’s achievable and threat of not having enough network segregation becomes less valid. Moreover, grading that risk as “High” can completely disable a business deeply rooted to a connected services paradigm.

Another hidden cost is related to the fact that while all security resources are thrown on imaginary threats, the real ones like those attributed to 3rd party vulnerabilities remain unaddressed and can lead to gruesome consequences (examples are many and don’t even need to be quoted here).

There is no simple solution for this problem. Your threat table will change only after you move the needle in the area of “common knowledge” in your organization.

Good luck with that!

Real Top Ten in Security


I don’t know what the most important thing for you in Top 10 2017-Top 10 – OWASP is. For me it’s vulnerability ranking or the way how the vulnerabilities have been ordered in that list. There are a few reasons why it’s important:

  1. Metrics and KPI believers, whose population grows in business world very fast will immediately map the ranking to priorities
  2. I didn’t see too many businesses who can handle more than two or three priorities at a time well
  3. OWASP Top 10 are very broad and cover almost everything in application security

I think, from this point of view OWASP’s Top 10 are not perfect at all since the current ranking simply doesn’t match reality and doesn’t address real security breaches that caught everybody’s attention lately. Let us take a look at a few of them: “Injections” that were leading the OWASP charts for many years, “Component Vulnerability” ranked as #9 and “Insecure Configuration” ranked as #5 in the 2017 list.

In reality #9 and #5 should be really #1 and #2 in my view, given that breaches like Home Depot, Target, Equifax led to the loss of millions of records of highly sensitive data and have been attributed to 3rd party vulnerabilities, while the latest SMB and ransomware related cases (Anthem, banks, governments) could be related to both insecure components and insecure configurations. Multiple security incidents with AWS S3 (Accenture, Verizon, Dow Jones) can be categorized as “Insecure Configuration” as well.

On the other hand, I can’t recall any significant security breach related to “Injections”.

I think, the major reason of this disconnect is that the method used by OWASP was based on surveys. As somebody who has interviewed many people and teams for the last 10 years, I can say that whatever you get from those interviews could be very inaccurate. In the most cases people simply don’t know what they are talking about, in other cases it could be related to personal preferences and interests to certain security domains, or to ambiguity of questions leading to inaccurate answers. In other words, it’s all about opinions and not about data coming from real security breaches.

Another important factor – a survey fatigue. I’ve been in a situation when various security assessors asked me hundreds of very ambiguous question and answering all of them accurately was simply not possible.

Real top 10 should be coming from real security breaches and their magnitude, e.g. you could try evaluating a vulnerability’s rank using the following formula:

(# of stolen records) x (record’s sensitivity)

or something along those lines.

Are Your 3rd Party Components Secure?

What is in common between Target, Home Depot, and Equifax security breaches? They seem to be different, Black POS was a root cause for the former two and Apache Struts2 vulnerability CVE-2017-5638 was a reason for the latter. In essence, they are both attributed to 3rd party vulnerabilities: Target and Home Depot use POS that they didn’t create, Equifax relies on Apache Struts2 that they didn’t build either.

The way how contemporary software systems are build has changed for the last two decades significantly. I still remember overheated discussions when business and IT were arguing vigorously about possibility of using open source software in a “serious” financial organization, and the answer at that time was rather “no” than “yes”.

These days, it’s not even a question. Even “serious” companies can’t afford building their systems from scratch anymore. If they try to do it, they would simply lose competition to their peers. The change was so dramatic that up to 80% of a contemporary system can comprise of 3rd party components.

The problem here is that even though adopting those components could be easy and free, definitely easier and cheaper than developing the same from scratch, the security of the adopted component was never free. This simple truth is not always understood well. Probably it’s just a mentality issue: we usually care more about the stuff that we’ve created than about the stuff that we’ve got for free or almost for free somewhere. Probably it’s about not understanding the risks that are coming from the adopted components, I don’t know.

My thought and a call to security professionals are simple: if you have 80% of 3rd party components in your system, you should probably dedicate more than 10% of your time and resources to the security of those components. As for now, the reality is different. You can participate in this poll to provide your feedback and to see how the resource allocation looks like in other organizations.

Why Information security is seen as an inhibitor to DevOps agility

To answer this question we would need to take a quick look at differences between DevOps, QA and Security when it comes to automation issues. I will have to write about things that are probably obvious for any security engineer who was practically involved in traditional AppSec activities such as penetration testing, dynamic or static code analysis.

The problem is that for some security executives who came to security from infrastructure, networking or development domains and have never run a security scan,  it’s not obvious at all.

Since situation when security execs are coming from different non-security domains is rather common (due shortage of security professionals), explanation below is crucial to answer the original question. To put it short, the difference is that DevOps and QA are very much deterministic, while security is not. The picture below illustrates my thought.

Ops: run_script(input) –> $? (0, non-zero)

QA: assert(condition) –> {true,false}

Security: scan(app) –> {HML…,false positive}

where High Medium Low and False Positives are really a human’s decision

In the case of architecture review and threat modeling, which are two other important AppSec activities that are often required by compliance standards such as SOC 2, it becomes even more non-deterministic where the results of analysis could be absolutely unpredictable and very much determined by an assessor background.

Needless to say that automation is nowhere close for this type of activities. The best we can do here is to get rid of unnecessary complexity, pseudo-scientific approaches to evaluating risks (e.g. DREAD) and describe the threats in a simple threat table with severities that everybody would easily understand, i.e. “Low”, “Medium”, “High”.

Not understanding this simple truth leads to euphoria and to setting up wrong expectations, e.g. a CISO who came from networking domain can say that a good networking appliance is all we need to completely automate security, while a CISO with a developer’s background will say that writing a lot of code will make security just as fast as DevOps and CI/CD. Needless to say that both are wrong and will not last long – they will have to leave as soon as their CEO or CTO understand that those promises will never materialize.

Does it mean that there is nothing we can do to automate security and make it faster? Of course not. As security engineers we can and we should, and this is what I’ve been talking about for almost three years by now: first at LASCON 2015, then at AppSecCali 2016 and just recently at  RSA 2017 DevOps event.

However, we should always take into consideration a non-deterministic nature of security and set up expectations right when talk to our execs.

The bottom line, security is seen as an inhibitor to DevOps agility because it is an inhibitor in many ways, but there are always opportunities to improve it by researching new approaches of doing it. In this regard, my big hope is a deeper penetration of AI and machine learning to the security domain. It won’t be easy, but the progress in IDS/IPS space makes me think that it will eventually help automating traditional AppSec activities as well.

Integrity in Security




It’s difficult to write about integrity in security, because it’s not about technology anymore, can be very vague and speculative. At the same time, not having integrity in security can lead to fundamental flaws that will undermine all other security controls. To be more specific about “fundamental flaws” think about compromised cryptography, in which case everything else that you do would not matter much.

What is Integrity?

You can find many formal definitions of course, but for me it simply means doing the right things, no matter what. “Right things” can be tricky here especially when a security SME or executive don’t have much experience in protecting systems and data, but since I’ve covered this case here and here already, I would assume that SME or executive have enough experience, know what they do and how security should be implemented. I will not also consider honest mistakes, because honest mistakes are not necessary related to integrity assuming that a person doesn’t have problems with admitting them.

Perils for Integrity

Any SME or executive who worked in security long enough has probably experienced one of more perils that could jeopardize their integrity:

  1. Senior management doesn’t completely understand the treat, but is willing to spend some time with security to understand it better.
  2. Senior management understands the threat, but doesn’t have time, money or human resources to address it now.
  3. Senior management understands the threat, but never provides all resources necessary to address it.
  4. Senior management understands the threat, but never provides any resources necessary to address it.
  5. Senior management doesn’t understand threats and never has time to talk to security about it.

Please notice that motivation for these types of behavior can be different – from not having enough resources to possible conflict with business goals. Understanding the motivation well is important for making trade-offs while preserving integrity.

Addressing the Perils

The first case is the simplest one. A security SME would need to identify the key business stakeholders and tell them a story at the right abstraction level.  Choosing the right abstraction level is very important. If it’s too low, you’ll lose them and it will be completely your fault that has nothing to do with anyone’s integrity. If it’s too high and generic, your story might not be compelling enough and nobody will buy into it. Try using some numbers such as a monetized cost of a possible breach or real life stories demonstrating reputational and financial losses occurred in other organizations.

The second case is not hopeless either. Make sure that business commitments toward security last by reminding them frequently that this is still an important outstanding problem that needs to be solved. Meanwhile beef up mitigating controls such as monitoring for this particular threat and if you find its pattern unfolding in production, use it as a hard evidence that the threat is real and needs to be addressed soon.

The third case is rather typical – you will never get all resources to address all threats and vulnerabilities that you’ve reported. What you can do is a better prioritization and addressing the most important threats first while monitoring for others just like in the second case.

The fourth case is tough. As I’ve mentioned above, try to understand their motivation. Probably the business is in such a bad shape that nothing has left for security indeed, in which case you’ll need to leverage all human and technical resources inside the security team to help business, development and operations by delivering more automation and monitoring to mitigate the risks. If business is thriving on other hand, but you’re still not getting resources, that’s a good reason for a serious conversation with the top echelons of management in your organizations.

The fifth case is extreme and doesn’t happen in real life often. Try finding at least one ally in the management ranks and use each opportunity to escalate the issues. If that doesn’t help, your own integrity is important for you and you don’t want to be a security window dresser, consider changing an employer.

Inspirational and Demotivational Examples

Fortunately, we have enough inspirational examples demonstrating a high level of integrity in security when people chose what is right over what is required by incompetent bosses or even governmental authorities:

  1. Martin Hellman thought that improved security is more important than possible prosecution by law enforcement. He has published his PKI work in 70s in spite of all threats and warnings coming from government and was right – security has benefited significantly, his work was widely recognized and revolutionized cryptography. He had vision and courage to implement it.
  2. A strong privacy advocate and a well known security dignitary, Alex Stamos, was arguing vigorously with an FBI director about cryptographic backdoors explaining why it’s dangerous and how it can compromise security for everyone.
  3. The same Alex Stamos has resigned from his CISO position at Yahoo when learned about its government backed secret spying program and realized that he could not do much about it due lack of support from CEO and the board.
  4. A number of security folks, cryptographers, legislators condemned secret government spying programs at different public forums and requested more transparency, because they thought that it will degrade security and undermine privacy.
  5. I’ve also seen many other honest folks in security leaving their well paid positions, because they didn’t agree with how security is handled in their organizations.

I don’t want to write much about demotivational examples, but unfortunately they are many as well. Just look at the inspirational examples above and think about adversaries of those decent folks that have been mentioned there.

Final Thoughts

Integrity in security requires a lot of courage, perseverance and intelligence. I think, to be a successful security professional, one should absolutely have it. On the other hand, employers who don’t understand it can undermine the whole security program in their organization, drive professionals out and create an environment where flourishing complacency kills everything good and real, while promoting “security as a window dressing” phenomena.


Biggest Security Problems

Credit: Thinkstock

Credit: Thinkstock


Contrary to what many might think, hackers are not the biggest security problem. As I’ve mentioned here, getting priority right is very difficult in security and the major security problems are related to that. Without pretending to be a single source of truth, I could formulate the first problem as:

Opportunistic Approach to Security

As described in Security Manifesto, there are many domains of security that an organization would need to address to make it right. However, a number of security executives who understand all of them well is very limited. There are two common ways for a security executive to become a CISO: (1) SME path, where an executive gets promoted to CISO, because he was very successful in one or two security domains, e.g. infrastructure and networking; (2) managerial path, where an executive becomes a CISO, because he was a successful engineering, operations or compliance manager.

The second case is the worst, because an executive will most likely try solving all security problems by means that she’s comfortable with, e.g. if she comes from a s/w engineering realm, she would say: “let us write a lot of code and it will solve all our problems”. The latter approach can be perceived by security neophytes as a new “revolutionary”, “one size fits all”, “silver bullet” solution and will make everything even more complicated and dangerous for the industry.

The first case is bad enough too, e.g. if CISO comes from law enforcement circles, he’ll focus on creating and enforcing policies, while a networking and infrastructure guy will immediately spend all security budget on very expensive networking appliances and neglect all other programs.

Security as a Window Dressing

The second big problem is lack of real support from senior management. It’s not common at all for any sane CEO, CTO, CIO or board of directors to say that they don’t care about security or that security is not their priority. I’ve seen only one VP of engineering in my life who had said openly that “security is not a priority” for his team. I would give this person all credits for his honesty, at the same time, I think that many executives who say that security is their priority are not necessary committed to it enough and are not willing to provide resources to implement the security at the right level.

This trend shows up when you talk to an engineering organization asking for resources – either people or money, or time dedicated solely to security tasks. They will never say “no”, but always come up with the excuses like:

  1. An important release is coming and we can’t jeopardize its deadline.
  2. They can lecture a security SME about importance of partnership. It can go like this: if s/w engineers don’t do what you’ve recommended, probably you, as a security SME, didn’t explain threats or mitigation plan well, you should not be policing or dictating anything to the engineering team, you need to be a partner and explain everything well to them and then they will implement everything you wanted. Needless to say how invalid these statements could be especially when significant engineering resources are required – no engineering team will embark on this kind of tasks without a proper authorization coming from a senior management, no matter how articulate the security SME was in explaining the threats and a proposed solution.
  3. Finally, they can declare the whole security program as a low priority or cancel it all together, because a new CISO told them that there is another, more important program that should be given the highest priority (see “Opportunistic Approach to Security” above).
  4. Some executives think that since they hired a CISO and a security team, security is not their problem anymore and is completely owned by the security organization.


Hiring CISO with the right skills is extremely important. An ideal CISO in my view should have broad knowledge in all security domains. Hiring CISO without any prior security experience is dangerous and doesn’t make much sense to me.

It’s primarily CISO’s responsibility to get resources and real senior management support. CISO should be vigorous and consistent in getting this message across and escalating issues related to lack of such support to the highest level if necessary.

Non-security executives should participate in making important security decisions and support security team with resources in other teams (operations, engineering, QA, etc.). A security program in any organization can’t be successful until everyone understands that security is a team game, where team is the whole company.


Security Manifesto

What is Security About

Security is about breaking and building. Building includes resilient systems with security embedded by default and security tools helping to automate the whole security process. Breaking is about reviewing the systems trying to understand where vulnerabilities could be found and proving that they could be practically exploited using commonly available tools and methodologies.

Common Security Myths

Common approach used by business often, namely – let us address “critical few” and all our security problems will be solved, doesn’t work in security and is dangerous, because security is just as strong as its weakest link, which most likely will not be included to the “critical few”.

Other common myths related to that are:

  1. Our system is secure, because we’ve implemented good security policies.
  2. Our system is secure, because we are compliant with all regulations where our organization is a covered entity.
  3. Our system is secure, because we’re using the most advanced and contemporary security tools placed by Gartner to the top right quadrant.
  4. Our system is secure, because we’ve written a lot of code to automate our security processes and integrate them well with all our automated security tools.
  5. Our system can not be defeated even by zero day attacks, because we use machine learning for fast intrusion detection and prevention.
  6. Our system is secure, because we have the best in the world security team and researchers.
  7. Our system is secure, because we have implemented a comprehensive threat intelligence program and are always one step ahead of any hacker group in the world.

What is Really Important in Security

  1. All of the above (see “Common Security Myths”).
  2. Being aligned with your organization’s business needs and building adaptive security by identifying the most important threats for your business and addressing them first.
  3.  Maturing and expanding your security tools, processes and coverage as your business grows and matures.
  4. Taking reasonable risks to allow business to be competitive and agile. Implementing a comprehensive security and losing competition to your peers because of that is not really an option.
  5. Always walking the fine line between security and usability. That’s the only thing that can make security implementation efficient.
  6. Being critical towards “well established” standards (think of DUAL_EC_DRBG) and “common practices” (Target was compliant with regulations and did what is “common”, but still got compromised)
  7. Assessing your threat posture well and understanding that your business might have specifics that others do not have. At the same time, always looking around to find solution that fit well your organization.


Be critical, understand that there is no “one size fits all” solution in security, look around to learn how other people and organization do it, but select only those solutions that fit your organization well. Analyze your organization’s security threats carefully before deciding what your short and long term priorities in security should be.