SJSI Quality3D meetup #3

Paręnaście dni temu zdarzyło mi się pojawić na https://www.facebook.com/events/225878038117535/ i niestety dopiero teraz znalazłem chwilę, żeby stworzyć podsumowanie.
Przy pozytywnych doświadczeniach generalnie tak jest, że nie ma za wiele o czym mówić. Inaczej wygląda sytuacja gdy jest negatywnie i chcemy się tym podzielić, żeby wyrzucić to ze swojego systemu i iść naprzód, upewniwszy się wpierw że każdy jest świadom naszych cierpień 😉 Tu cierpień nie było ani odrobinę, przez co chwilę zajęło mi napisanie podsumowania.
A tak poważnie, było dobrze, nawet bardzo dobrze.  Miałem szansę spotkać się z bardzo przyjemnie aktywną grupą, z którą mogliśmy prowadzić dialog, zamiast prawić jednostronne prelekcje.
Taki format, real time Q&A odpowiada mi najbardziej, bo wtedy czuję, że nie tylko mogę poznać ciekawych ludzi ale też wnieść wartość przez proponowanie rozwiązań do realnych, kontekstowych i indywidualnych problemów.
SJSI organizuje ostatnimi czasy bardzo ciekawe wydarzenia, na które zapraszają ludzi z wielu dyscyplin, by ci podzielili się swoja wiedza i doświadczeniem. I dokładnie w ten sam sposób sytuacja miała się z moim wystąpieniem. Zostałem zaproszony i bez chwili zastanowienia krzyczałem “TAK, TAK, TAK!”. Możliwość dotarcia do nowej grupy osób ze swoimi ideami, pomysłami oraz gotowymi recepturami rozwiązań do szansa której nie mógłbym odrzucić.
Jestem wdzięczny za możliwość docierania ze swoja wiedza i doświadczeniem do innych. Za każdym razem, podczas każdego występu, mam nadzieje na dostarczenie jak największej wartości ludziom którzy zdecydowali się zainwestować swój czas i pojawić się na wydarzeniu by słuchać własnie mnie, Jestem szczególnie wdzięczny za mile przywitanie oraz za interakcje podczas prelekcji.
Mimo, ze początkowo byłem myślami gdzieś indziej przez realizowany wcześniej projekt, to po 5 minutach już byłem all-in i totalnie pochłonięty przez interakcję z uczestnikami. Było dobrze!
A teraz czas na linki o które pytaliście.
Książka:
Prezentacja:
Artykuł o tym jak przebić się do branży security:
A w skrócie, event był o:

“Najlepszych rzeczach, jakie możesz zrobić dla bezpieczeństwa Twojej firmy w ciągu najbliższych 3 lat”

Firmy, ich pracownicy oraz cała społeczność IT jest zakłopotana i lekko zagubiona w ogromie zagadnień związanych z bezpieczeństwem organizacji. Jest tyle szumu informacyjnego dochodzącego z każdej strony, że ludzie nie do końca wiedzą, którą drogą pójść, aby zwiększyć bezpieczeństwo swojej firmy. Czy powinni testować manualnie czy automatycznie, czy powinni zamawiać usługę pentestów, czy używac programów bug bounty, czy powinni trzymać swoje dane w chmurze czy w klasycznym centrum danych.
Podczas niniejszej prelekcji postaram się odpowiedzieć na te i wiele innych pytań – schodząc do poziomu technicznego. Moim celem jest podsunięcie Wam pewnych pomysłów i gotowych rozwiązań, tak abyście mogli skupić się na realizacji istotnych zadań.

oraz o

 “Testowanie najpopularniejszych błędów bezpieczeństwa – rozwiewamy mity o trudności pracy jako bezpieczniki i pokazuje że może robić to każdy z Was.”

W świecie bezpieczeństwa krąży legenda o tym, jak wyjątkowym trzeba być by zajmować się testowaniem zabezpieczeń i ochroną organizacji.
W rzeczywistości – uwaga, uwaga! -wszyscy jesteśmy ludźmi i jeśli coś udało się zrobić jednej osobie o podobnym do Ciebie profilu, to możesz to zrobić i Ty.
Podczas półtoragodzinnego warsztatu pokażę Wam praktyczne narzędzia oraz przybliżę sposób myślenia konieczny podczas testowania bezpieczeństwa, dzięki czemu – niezależnie od obecnej profesji – będziecie w stanie wgryźć się w temat testów bezpieczeństwa, testów penetracyjnych, audytów bezpieczeństwa i tym podobnych.

InfoSec Career Paths vs Programming Skills – The Basics

On Peerlyst, in my Q&A session, Eric Geek‍ asked:

Is being a great developer vital when choosing information security as a professional career?

My answer below:

Beneficial? Yes.
Necessary? By no means. Demand for development skills in infosec is raising, but the demand for general infosec specialists is growing even higher.

I know many fantastic security professionals, who just hate programming. They’ll code a bit to help themselves, to build some simple automation for their tasks, but they’d never write any serious application.

The market for infosec professionals is so wild, that it’ll eat almost anyone with any interest in security and some technical acumen.

Software engineers can easily become information security specialists

… and they bring a lot to the table, for organisations that need that kind of skill set.

The work required for software engineer/programmer to become security specialist will vary a lot depending on the person and their existing skills, aspirations and predispositions.

If you are a software engineer, then I would recommend to learn more about application security and then move into secure software engineering roles. While in that position, your goal should be to gain exposure to technologies and security processes. This will make it easier for you to switch between other professions within the cybersecurity industry.

If for example you’re a software QA engineer and you know how to test software, it doesn’t take much to start including security tests in your day to day work. It will allow you to realize after a couple of months that you’ve gotten the grasp of quite a few security issues!

If you’re a network engineer, then it makes sense to learn more about infrastructure and network security in order to move into positions such as network security engineer, incident response engineer, or a network penetration tester.

This approach should help you if you want to transition into cyber security at low cost and low anxiety. It makes it easier to make that transition, because if you have a solid background in building something it will come easier to you to figure out how to break it and secure it.

If you’re comfortable in a given specialisation, you won’t feel scared of the amounts of new knowledge you’ll need to possess and this will lower stress to ease you into the learning process.

So a software engineer who wants to transition into security role, should try applying security principles to whatever they’re currently doing — try to learn how to break the things they’ve built, and then how to make them more secure and impenetrable as possible. If you reiterate enough, you can become a security-savvy engineer who can easily add ‘security’ in front of their existing job title and becoming a security specialist in any given field.

I would suggest adding some good eye opening resources to your knowledge base. One that holds value for all types of security operations is learning about basic Security Architecture Principles. And then learning more depending on which fields of cybersecurity you want to explore.

Here are some great materials for Web and Mobile Applications:

  • OWASP TOP10
  • OWASP Application Security Verification Standard(ASVS)
  • OWASP Security Code Review Guide
  • OWASP Web Applications Testing Guide
  • OWASP Mobile Testing Guide

Network and Infrastructure Security:

But the most foolproof and effective methods of learning security skills to me is doing the following: google stuff out. Start doing some fundamental research in your craft and google is your best friend here, and always will be. Sooner you learn the art of googling, is better because we use it a ton in our day to day work.

If you’re writing code in C++, then google “C++ security vulnerabilities”, or “writing secure code in C++”. If you’re deploying apps in cloud, such as AWS, then google “how to secure AWS applications”, “secure deployments in AWS” and so on. Learn as much as you can from search results and from the latest news, this will expand your security expertise as time goes by.

This way you’ll learn security skills relevant to what you’re currently doing and keep up with the latest cybersecurity trends, which will allow you to live and breath that knowledge and put it to practice in your projects.

You can become valued security professional from any IT specialization

I often get a question on how to become a security professional. And my answer is – by becoming a professional in any other field, or by working your way up from anything you’re currently doing. Reverse engineer requirements from job offers in your area and learn what they want you to know. Then strike at them as soon as you feel comfortable with your skills. Research & reverse engineer job offers & learn & practice & go on interviews & understand what you were missing and why they haven’t accepted you & learn the missing pieces & rinse & repeat until you get a job.

Appreciate the journey and don’t underestimate the value of having a varied background, do it all at the beginning because you’ve got time.

I started my adventure in IT from the very bottom, working as a computer technician, network admin, web programmer, and system administrator. After many years, I got involved in security. I do not regret the time I spent in previous positions because taking an indirect path provided many valuable experiences, all of which gave me perspective. My range of experience allows me to understand the problems many employees face, enabling me to make better decisions for the companies and teams I work with. I believe the security industry could benefit greatly from more diversity

However, if we’re considering a position where you have zero experience in security whatsoever, but have experience in other fields of IT, then I recommend becoming an expert in a different field. Start applying security concepts to your field of specialization. This has worked for so many talented professionals I know. Too many people want to get into security without prior experience in anything IT related. This doesn’t make most of them very valuable professionals because they tend to make myopic decisions without considering business context. Security is merely an addition to business operations, designed to support its longevity. It doesn’t exist on its own.

You can read pentesting and bug bounties blogs, but pasting random payloads without deep understanding will prevent you from contributing much to your organization. Dive deep into anything you learn, stay curious, and enjoy ‘expert’ status in a few years.

Here are a few viable and popular career options:

Web App Security TesterSome skill in coding is good. It’s not necessary, but it is beneficial and it’s usually what separates wannabe experts from true experts. Learn how software stacks work and get a handle on web programming languages like Java, PHP and their respective frameworks. To break something and improve its resiliency afterward, you should understand how it all works. Once you review all the OWASP resources, you’ll know what to do next

Network SecuritySimple bash/perl/python/ruby coding if any. Create a local lab network consisting of various components. Deploy services like LAMP (Linux, Apache, MySQL, PHP) stack and research how to secure each element. While building, study what issues can arise during configuration and maintenance so you know what to avoid and how to test them when sysadmins hadn’t the time, interest or knowledge to do so. Then, focus on PTES (Penetration Testing Execution Standard) Technical Guidelines to discover ways in which penetration testers and hackers can attack your network. Reverse engineer their methods to build proper defenses against future attacks.

Compliance and AuditingZero programming skill required for most roles. Learn about underlying technology and business models. You want to understand how businesses operate so you can protect them and ensure new regulations don’t hinder company innovation. Grab some good business books and gain business exposure by learning from executives and managers with real-world experience. Study industry best practices, like those from the Center for Internet Security, as well as regulated standards like HIPAA, PCI-DSS, DISA STIG, ISO 27001, SOC2 to understand how to make your organization compliant without negatively impacting productivity.

Cryptographer/CryptoanalystDepending on a chosen niche, coding may be just an addition for tests of implementations, protocols and algorithms cracking. If you want to become an expert in this field, I recommend attending a university with strong mathematical and cryptography programs. This is a fascinating field that requires prior and substantial mathematical knowledge, so if you go through heavy math, learning to code will be your least worry 🙂

Security ConsultantDepending on the context, most roles require zero coding, some require some. This position will help you gain experience working in IT or IT security, so you can understand the business and broaden your horizons. If you decide that you want to stay in consulting, research what big companies are doing, technology they use, and regulations they’re subject to, then learn how to manage these for them.

Vulnerability ResearcherAll-in or ZERO. This narrow specialization requires focus in at least one field. Become proficient in at least one programming language, framework, and operating system. Then focus on a narrow set of functions in a given product or service. Examples include studying assembly, C programming language, learning how video transcoding works, and identifying weak spots in a library such as FFmpeg. Zero coding is required if you want to be a bug bounty hunter, who keep calling themselves “vulnerability researchers”

Software Security Expert – Software engineers often become security experts. Be proficient in at least one technology stack, then apply all relevant security knowledge to making products safer. Strengthen security across your organization, responding to the demands of your colleagues and customers.

If you want to speed up the process of becoming values security professional, pick technology that truly interests you and learn as much as you can about it. So instead of being Web App pentester, become a Node.JS security expert. Be a specialist, not a generalist. Go for a narrow niche. Find something that sparks your curiosity and become passionate about it. Know things only 0.01% of people using the technology knows and your pockets won’t be able to hold amounts of money companies will pour into it 🙂

The most important advice here is to look for employment as soon as possible because nothing can beat the quality of learning you get on the real job. It’s the actual job and job market that shows you what is required and what is not.

Almost ZERO programming experience required for Penetration Testers

Don’t get me wrong, pentester who knows how to program and code is invaluable, but some pentesters are such great manual testers that they will find a great employment no matter what. Despite the current state of pentesting in US where actually cool stuff is happening, you still have 95% of countries who’re a decade behind in terms of their cybersecurity posture, and in there all you need is to study OWASP Testing Guide to fill your pockets big time.

Let’s consider a few scenarios and then jump to job specific recommendations.

If you already have some security experience, then check out a few renowned books that are highly rated on Amazon with the title containing word “Pentesting” to build your foundation. Then go for an Offensive Security’s lab and certification – OSCP, which as of now is the most respected entry-level certification for penetration testers. Consume as much content as you can, but don’t allow yourself to get lost in the universe of theory. The best pentesters are those who put their knowledge into practice and get their hands dirty.

If don’t have security experience but work in other IT fields, then the recommendation is for you to become an expert in a different field and then start applying security concepts to your field of specialization. That route worked for many great people working in the industry that I know. If you’re a Java programmer, study how you can test applications written in Java. If you’re an IT OPS engineer deploying services in the cloud(AWS/GCP/Azure) then learn about potential security issues and learn how to pentest those services. Learning will come much easier if you have the proper background.

If you haven’t ever worked in IT, but want to work in security, well this one is tricky and hard because general security isn’t an entry-level role. Too many people want to get into security without prior experience with anything IT-related, which doesn’t make them very valuable professionals because lots of decision they make are myopic and don’t consider business context. You can get easily get excited reading pentesting and bug bounties blogs, but as long if you’re just pasting random payloads without deep understanding of a matter, then you’re not contributing much to your organization. Same way you won’t get a sixpack by reading about pushups, you won’t become a great penetration tester without going into the field and testing stuff.
So go deep in anything you learn about, and enjoy ‘expert’ status in just a few years.

And now let’s take a look at some of your options when you’re completely fresh to the field.

Web/Mobile App Pentester  – Learn how to code. It’s not necessary, but beneficial and that’s what usually differentiates expert wannabes and true experts. Learn how software stacks work to get a grasp of web programming languages such as Java, PHP and their respective frameworks. To break something and improve, then it’s the resiliency afterwards you should understand how it all works. It doesn’t mean you must be a guru software engineer, but you can’t go wrong knowing the basics.
Once you’ve completed all the resources from OWASP you’ll know what to do next.

Network/Desktop Apps Pentester – Create a local lab of a network with various components in it. Deploy some services such as LAMP(Linux, Apache, MySQL, PHP) stack and then google out how to secure each of those elements. While building, study what issues can arise during the configuration and further maintenance, so you know what issues to avoid and how to test them in the future in other environments where sysadmins hadn’t had time, the interest or knowledge to secure their instances the way you could. Navigate to PTES (Penetration Testing Execution Standard) Technical Guidelines and see what are the ways penetration testers and hackers could potentially attack your network, then reverse engineer their attack methods and build defenses so they attacks no longer work.

Specialized Pentester – Pick one technology and go as deep as you can. So instead of being a Web App Pentester, become Node.JS Security Expert. Become a specialist instead of being a generalist and cut the learning process in half or even more. Find something you’re curious about, learn more about it, and become passionate about the field, put in a few solid years of dedication, and you’ll get whatever you want to have. (Well, not precisely everything you want, but you get the point)

Red Teamer – All of the above recommendations apply including social engineering and physical security attacks. You may not have the technical predispositions to be a great web pentester, but if you have been gifted with empathy and social skills then you can still achieve a lot!

There are hundreds of blogs of people who documented their journey, and I recommend you to look into real world examples of people who’ve moved into a pentesting career. Learning from the successes and mistakes of others is very cost-effective. Also, I’ll recommend you a bulletproof method of finding a job as a pentester. An importance most people don’t realize:

  • Find a few dozens of pentesting job offers in your area
  • Extract the most common requirements, both high level and detailed technical skills
  • Know what to study and what employers really need
  • Don’t waste time on learning everything. Learn the minimum possible to get the job and be a valuable team member. From there your career is highly malleable, you can adapt to what your organization needs you to do.

So yeah, you can flourish in the infosec field without having more than one week of study in programming. The market is the ultimate judge. Some companies require programming skills as a must-have, and some don’t care. Find what suits you best and keep on rockin’!

Tematy w security, o których nie mówi się wystarczająco dużo, czyli element ludzki

Dziś na podcaście gościmy Andrzeja Dyjaka, specjalistę ds. cyberbezpieczeństwa, z którym będziemy rozmawiać głównie o tematach związanych z najnowszymi błędami bezpieczeństwa, ale nie obędzie się bez rozmów o holistycznym podejściu do bezpieczeństwa i tym jakie aspekty psychologiczno-socjologiczne powinniśmy uwzględniać jako community security.

Andrzeja mozecie znaleźć na https://dyjak.me | @andrzejdyjak | https://www.linkedin.com/in/andrzejdyjak/

a nagranie na:

 

 

Jak wygląda praktyczna implementacja DevSecOps

Agile’owe podejście do bezpieczeństwa brzmi wyśmienicie i wielokrotnie spotkałem się z sytuacją, w której ludzie nie wiedzieli jak się za to zabrać. Wobec czego, jakiś czas temu stworzyłem podcast wprowadzający w świat DevOps i DevSecOps, natomiast były to bardzo lekkie materiały, które nie zawierały żadnych sekretów, lecz raczej coś na postać historii tych ruchów.

Wczoraj, opublikowałem półgodzinne nagranie w którym opowiadam już z sensownym poziomem szczegółów o tym jak to wygląda w realnym biznesie, jak do tego podejść, co można za pomocą DevSecOps osiągnąć, jakich narzędzi się używa, jak automatyzować procesy zapewniania bezpieczeństwa i parę innych ciekawych rzeczy, o których nigdzie indziej w polskim internecie nie usłyszycie.

Także polecam, bo wyszło całkiem fajnie!

 

I pierwszy, wprowadzający podcast:

TOP 9 Rules To Maximize ROI Of Bug Bounties And Penetration Tests

Originally posted at testarmy.com

Having worked on both sides of the fence, I want to share my biggest lessons learnt during my career that entailed:

  • being a penetration tester and red teamer
  • being an accomplished bug bounty hunter
  • working as an internal QA engineer, Security Engineer and Security Architect a’ka blue teamer
  • running and maintaining bug bounty program for a handful of companies
  • worked as a head of security reporting to the board of directors for maximum ROI of security initiatives, including penetration tests and bug bounties

Here is a list of action items I recommend you to take during and after penetration test/bug bounty cycle. This list is based on the most common gaps I’ve noticed at the companies I’ve worked with and the things that to me made a huge impact ROI-wise.

By implementing these steps, you’ll be able to get much higher return of investment from penetration tests. If you’ve already spend your money, let’s make sure you’ve spent it well and squeezed max out of it.

  1. Provide all information to pentesters as beforehand.

You want to make sure that pentesters don’t waste too much of their time on reconnaissance. Provide them with documentation on the product, video recording how your product works, and a list of APIs and endpoints you want them to test. In general, penetration testers will know what to go after, however if you have hidden APIs, or want to speed up the process, it’s better if you provide them the information beforehand.

2. Don’t play games and don’t block pentesters as they do their job. You’re all in the same team and should share the common goal to make your organization safer

The mindset shift is a huge thing. I’ve met number of security teams, that were literally fighting with external pentesters, because they were afraid of their position and ego. You hire pentesters to do the work for you and to provide maximum value to your business, so it’s not smart to waste your money while you argue with pentesters and block their testing environments.

Depending on corporate culture, it may be a good idea to have a separate – such as compliance/audit – team to coordinate external testing, to avoid conflict of interest.

3. Be humble and thoroughly follow pentesters recommendations in terms of issues remediation

Don’t fight it, when pentesters provide you information about the issue severity and its guidance. It may sometimes happen that with internal business knowledge, you can perform better risk analysis and assess that the issue has different severity for you. However, keep in mind that most often than not, pentesters know what they’re doing and it’s not their first assessment(I hope!) so when they provide you an information about the issue, it’s likely to be legitimate. It’s generally good idea to follow their remediation guidance, to make sure you’ve addressed the issue in-depth and then request re-tests.

4. Find the root cause of every single issue and learn what you can do better next time.

Stay focused on the big picture and think about other places where the same issue may exist but wasn’t found by pentesters. As opposed to simply fixing individual bugs, dig deeper into your codebase to find out if the same issue doesn’t happen in other applications. Then review your software engineering practices to see what could be done better to stop those bugs from appearing in the first place.

5. Have your engineering teams learn from pentesters and study pentest report

Don’t keep it all for yourself and have everyone learn from the report. Use it as an interesting exercise and learning experience. Pentests at most companies happen once or twice per year, so why not maximize the outcome. Thanks to that software and QA engineers can learn how to apply that knowledge in their day to day work such as to add it to existing test cases.

6. Ensure developers have complete understanding of all issues

You need to take ownership over the reports and don’t just throw it at employees. You want to make sure everyone has good grasp of security awareness, so they can address them well as well as use that knowledge in the future to build more robust apps. If something is complicated it won’t get easily remembered and put into action.

7. Cover identified bugs with solid regression test cases

You don’t want pentesters to find the same bugs over and over again. Not only it’s a waste of money, but that’s an additional exposure, because if regression pops up, attackers may abuse it before your next pentesting engagement.

We’re performing penetration tests to improve our products and company, so if you’re not going that extra mile, you’re leaving a lot on the table.

8. Once in a while check changes made by pentesters, visit their profiles used for testing to catch unexpected regressions.

It makes a lot of sense to clone the activities that were performed by pentesters, and build standalone testing scenarios out of it. When you login to the pentesters’ account in the testing environment, you may notice much more bugs than they reported. Security testers, focus on reporting security issues, and most often don’t waste their time on reporting UI/UX issues, that may have been identified during security tests. So just checking their environment to see if e.g. not expected encoding didn’t break the UI, will be beneficial, and again will be something to share with internal QAs so they can improve their test cases.

9. Review logs to catch unidentified bugs

Some things aren’t exposed to the user, which means that security testers may have touched some fragile system and maybe had even broken it, but they weren’t aware of it. If you review the logs, you may be able to find some unhandled exceptions, Internal Server Errors, and other indicators that may allow you to improve robustness of your code and systems.

Thanks to making yourself comfortable with the logs generated by penetration testers, you’ll be also able to create security monitoring around your access/application logs, to detect potentially malicious hacking attempts. If some keywords happened to appear in logs only during pentesting engagement and never before, then attackers may perform tests in the same fashion. If you create alerting around that, you may be able to spot the attackers and allow yourself to respond to the threat.

In my career I’ve met only a handful of companies that taken such wide range of activities during penetration tests. If you follow this guidance, you’ll optimize your spendings and should be more satisfied with general return of investment in security tests.

Here Is What We Should Teach All Software Developers About Security

I’ve received this question a couple of weeks ago and I believe it’s valuable enough to spread my thoughts on the subject here as well.

Having been a university lecturer myself I truly believe there is much more we could be doing. It doesn’t mean we need to push a lot of new knowledge on students, it’s just enough if we share with them the principles.

Educators need to make it their goal to try to teach software engineers anything about security because 1% is better than none. Instructors should strive to make lessons relevant and engaging while making it as simple as possible. You want to show software developers that application security isn’t really as hard as it’s portrayed. If we lower the entrance bar and we help them understand where they can find high quality knowledge, then they’ll be more eager to learn about the subject.

The common problem we see among software engineers coming from a variety of background isn’t a complexity of security, but that they just haven’t been made  aware of the need for application security.

We certainly don’t want to overwhelm software developers with loads of new knowledge because they already have a lot to learn in their own specialisations. A good start would be to outline the basic security principles. These are fundamental principles that would – hopefully – change their naive mindset and prepare their software for facing the real, dangerous world.

Here are some of those key security principles: (paraphrased for brevity)

 

  • Minimize attack surface area

Every feature that is added to an application adds a certain amount of risk to the overall application. The aim for secure development is to reduce the overall risk by reducing the attack surface area, so think twice before you write that next feature/functionality and expand your code. More code = more places where mistakes could’ve been done.

  • Establish secure defaults

There are many ways to deliver an “out of the box” experience for users. However, by default, the experience should be secure, and it should be up to the user to reduce their security – if they wish to and if it’s allowed per design.

  • Principle of least privilege

The principle of least privilege recommends that accounts have the least amount of privilege(s) required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions.

  • Principle of Defense in-depth

The principle of defense in-depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in-depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur.

With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.

  • Fail securely

Applications regularly fail to process transactions for many reasons. How they fail can determine if an application is secure or not. So when an application fails or throws an exception, it should default to the lowest privileges and accesses possible.

  • Don’t trust services

Many organizations utilize the processing capabilities of third party partners, who will more than likely have different security policies and posture than you. It is unlikely that you can influence or control any external third-party, whether they are home users or major suppliers or partners.

Therefore, implicit trust of externally run systems is not warranted. All external systems should be treated in a similar fashion.

  • Separation of duties

The key to fraud control is the separation of duties. For example, someone who requests a computer cannot also sign for it, nor should they directly receive the computer. This prevents the user from requesting many computers and claiming they never arrived.

Certain roles have different levels of trust than normal users. In particular, administrators are different to normal users. In general, administrators should not be users of the application.

  • Avoid relying exclusively on security by obscurity

Security through obscurity is a weak security control and nearly always fails when it is the only control. This is not to say that keeping secrets is a bad idea, it simply means that the security of key systems should not be reliant upon keeping details hidden. The security should rely upon many other factors, including reasonable password policies, defense in depth, business transaction limits, solid network architecture, and fraud and audit controls.

  • Keep security simple

Attack surface area and simplicity go hand in hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code.

Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.

  • Fix security issues correctly

Once a security issue has been identified, it is important to develop a test for it and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential.

 

It would make a huge difference if we educated software engineers and made them aware of those risks. It’s important because even without going deep into details and technical specifics, we can shift their mindset one it at a time.

We teach software engineers — and for a good reason —  how to be good citizens and how to build, which after many years compound and create a builder mindset. Security assurance on the other hand is mostly about breaking and finding holes in a “perfect” creature.  Builders generally don’t think about the bad stuff, because they’re always striving for better, prettier and something that’s more functional. Sharing with them the basics and showing what can possibly go wrong doesn’t cost much, yet is a great starter.


And then if we want to go deeper, which we should — we should teach them about security issues classified in OWASP TOP 10, and train them into performing basic security testing. This is to embrace the breaker mindset and to widen their skillset and horizons.
Although OWASP produces educational content mostly for web and mobile applications, it can also enrich the mindset of desktop apps developers and other people working with software development. However, we can’t just throw those resources at everyone. To be effective, we must provide relevant training, so students don’t feel like they’re pushed to learn something they won’t ever get to apply in their careers.

 

Once we’re done with face to face trainings, we should provide them with resources they can use on their own. Pointing them to books, websites and courses which they can use to become more security-savvy is really helpful and decreases the discomfort that comes with entering a new field of study.
As for Web developers, we should point them to content such as:

  • OWASP TOP 10 – A list of most critical web application security risks
  • OWASP Application Security Verification Standard – A quick checklist that can be used for ad hoc purposes to verify compliance with security standards
  • OWASP Testing Guide – Extensive guide into web application security testing
  • OWASP Security Code Review – Detailed book on how to perform whitebox code reviews to identify security bugs

 

Depending on how much time and resources we can and are allowed spend on it, we should go beyond and provide students with access to variety of other resources. Think of books explaining the security concepts behind the components they’ll use on daily basis, whether as a user or while integrating it into their software.
Let “The Tangled Web” book be an example of an excellent choice to better understand web browsers and frontend’s security. 

Whatever you decide to choose, make sure you’re actions will inspire them to continued education. In my experience, the best way to learn is by applying theory to real-life problems and putting freshly possessed to practice. Human beings learn by making and breaking, and everything single mistake can be converted into positive learning experience, thus making them better developers.

If we don’t focus on addressing the issue at the core(formal education), we’ll have hard time keeping current pace of innovation, because we’re being constantly derailed by problems we try to fix with ineffective, myopic mindset. So keep exploring, keep testing and keep moving this field forward.

Good luck, ’cause you’ll need it. We all do!

Priceless braindump resources from Chris Roberts. Truly inspiring.

InfoSec folks, I’ve got a rare gem for you!
Priceless braindump resources from Chris Roberts. Including Data Security Maturity Model + beautiful and deep articles from a man on a mission.

Check this out:
https://www.dropbox.com/sh/8wuc9szpiuv8ir6/AACcLVcVBHRgI7hA5uNehIsfa?dl=0

Some serious goodness shared today by legendary Chris Roberts !

Most notable docs IMO:

  •  2017 stuff/ Blogs 2017 catalog
  •  Blogs catalog

^ extremely mission driven articles. Made me feel much more comfortable and safe with my approach with >90% renders Chris’ approach to infosec as a whole

  •  Data Security Maturity Model!!!
  • Black Report
  • list of great books and articles

 

True gems, I’ve read it all and loved every single minute spent on it!
Thank you once again for sharing Chris. I’m truly delighted!

Do you really believe you are in control of your online privacy and data?

In most cases, your data is NEITHER safe NOR private if you’ve ever put it on the Internet.

Most of us blindly believe that if we pay extra money for a product from reputable brand, then we’ll receive a high quality and secure thing.

It doesn’t work this way. Not at all. Most companies don’t give a damn about your #safety, your #privacy or security of your data as long as they can rock’n’roll thanks to the money you gave them.

We make these exchanges on daily basis without consciously realizing the hidden costs on our side.

Application security, especially on this level, for a company with revenue of 19 billion dollars is NOT hard by any means. There is no excuse or explanation for this. They just don’t care and it doesn’t make them much more different from 90% of companies you use on daily basis.

What can be done? Not much, online privacy and safety are myths and legends we can tell our kids as a bed time story. Like most bedtime stories, it’s something we would believe, yet we do believe in this one.

It would require a society who understands and publicly shames companies with bad security practices, but that’s not going to happen.
Most people don’t want to care and even tho they’re terrified and nod their heads to Orwell’s “1984”, they won’t take any action.

Rant’s igniter: https://www.techspot.com/news/72612-western-digital-cloud-drives-have-built-backdoor.html

Align your actions with your belief system

The real effectiveness in InfoSec begins when you realize you’re not in hacking industry, but in the money-saving industry. Your job is to minimize business’ operations costs and decrease the risks of potential financial losses. It ain’t a bit about flashy tools and empty phrases.

You want to be treated seriously at the workplace and have #executives finally respect you for your greatness? Demonstrate your business awareness and prove them by actions that you really understand why you’re getting your paycheck.

It’s not just a preach to help businesses do their stuff. It’s deeply important, because if you finally understand that, you’ll save yourself a ton of resentment, social anxiety and may be you can save yourself even from depression. It’s easy to become a nihilist in InfoSec, so change the way you think about your role in the organisation and see yourself flourish. Your life and your work matters.

But don’t let things overwhelm you, just because you’ve failed to set a proper context for your life and actions.