Menu

Dimensional Data

kiuwan
Kiuwan-Romania-DevOpsApproachto Code Security

Understanding the DevOps Approach to Code Security

Noutați

DevOps generally means integrating software development (dev) and information technology operations (ops) to speed the lifecycle, deliver better features, updates and fixes, and more. What’s sometimes missing from this perspective? Code Security. Here’s a description of how to bring security fully into this picture, and integrate it all the way from design, through development and test, and into production. DevOps is a set of software development practices that combines software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives. Most experts agree that DevOps actually combines three key ingredients: People, meaning developers and their hangers-on (testing, QA, and so forth), IT professionals, and other “interested parties” – usually stakeholders in what’s being developed and maintained. Process, meaning a deliberate and calculated focus on the software development lifecycle as a formal process, that uses methods like Scrum to codify and stimulate team communications among all the people involved (not just developers, but everybody) with CI/CD (Continuous Integration and Continuous Deployment) to continuously integrate code changes and deploy applications to production as needed, scheduled, or available. Tools, meaning software tools used to help the people fully implement the process. Tools to enable IT automation are essential to making DevOps work properly According to The DevOps Handbook, the real essence of DevOps depends on “applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream.” It goes on to mention a slew of bodies of knowledge that include Lean, Theory of Constraints, resilience engineering, learning organizations (continuous learning and continuous improvement)Kiu, safety culture, human factors, and more. On the leadership side, it cites to high-trust management cultures, servant leadership, and organizational change management. DevOps isn’t just a combination of Dev and Ops, it’s actually an entire frame of reference for doing development and IT correctly, responsibly, and repeatedly. Where Does Code Security Come Into DevOps? The short, flippant answer to this question is correct, but overly brief – namely “Everywhere.” That is, security has to be part of the process used for DevOps, it has to be built into the tools used to do DevOps (or make it happen), and, above all, it needs to be high up in the minds of the people involved in DevOps. Kiuwan offers a way to bring security in throughout the entire DevOps lifecycle. It offers the ability to scan code for vulnerabilities and even to automate relevant remediation (where available). But because the Kiuwan tools integrate with various well-known development environments, this makes scanning code for security vulnerabilities, adoption of security coding standards, and automatic error prevent part and parcel of the development, test, and update/maintenance processes across the entire lifecycle. Kiuwan’s IDE integrations encompass the following families and items: Eclipse-based IDEs: Luna, RAD, IBM Rational Developer) Microsoft Visual Studio and Visual Studio Code JetBrains-based IDEs: Intellij IDEA, PhpStorm, PyCharm, Android Studio, and CLion Thus, organizations gain lots of traction to build security (and code scanning) into all phases of their development, maintenance, and deployment efforts. This is why some refer to the most productive mindset in this arena not simply as DevOps but rather as DevSecOps to put security on par with the equally important frameworks that help to formalize and […]

Read More
DevSecOps COVID-19 in Romania

What DevSecOps Teams Can Learn from COVID-19

Noutați

Over the last few months, the whole world has fundamentally changed due to the emergence of a novel coronavirus, COVID-19. The highly infectious nature of the virus, its devastating impact on vulnerable individuals who catch it, and the lack of a vaccine have allowed COVID-19 to become a global pandemic. Institutions of all types have been closed and life as we know it has been fundamentally changed. Officials argue about the “right” way to emerge from this self-imposed shutdown, but all agree that our world is different now. DevSecOps is one tiny part of the global economy, but it can benefit from the lessons this crisis can teach us. At its core, a DevSecOps philosophy exists to prevent a major disruption like COVID-19 from threatening an organization’s survival. That is not to say the DevSecOps could prevent a real-world virus, but how we approach an emergency should shape the way our DevSecOps teams approach their charters. We can all learn a great deal by looking at the COVID-19 crisis and examining how we can do things better next time.  The element of surprise Don’t underestimate the humanness of any team. Group dynamics affect every team’s performance and its ability to function effectively, and DevSecOps is no different. In fact, the degree to which a DevSecOps team adds value to its organization depends on its ability to function productively. Contentious competition rarely results in positive team outcomes. The fact is that we — as a community, a nation, and a global population — were not ready for COVID-19. There were a few qualified individuals who warned of such a pandemic for many years, but their warnings didn’t gain much traction. Traditional risk management had placed a pandemic like COVID-19 too low on the priority list to warrant a sufficient preparation budget. We flat out missed it. Hindsight is 20/20, and it is so easy to criticize others in retrospect. That isn’t the purpose here, and analysis for criticism is not very productive. Critical analysis, on the other hand, can be very productive. Those are very different approaches. Critical analysis of how we prepared for and managed the COVID-19 pandemic can provide DevSecOps teams with valuable insight into how to handle crises.  This novel virus took everyone by surprise. We had not properly recognized the threat, we had not invested in preparing for such a threat to be realized, and we failed to understand the gravity of the problem in its early stages. Analysts depended on limited and incomplete data to fuel models that were speculative and dynamic. Traditional data and models built for other similar outbreaks weren’t able to provide the granular results necessary to take decisive action. Authorities at all levels took good-faith action based on their interpretation of the latest models, but interpretations differed, and the resulting actions weren’t coordinated in many cases.  The DevSecOps takeaway is that our teams exist primarily to avoid competing for jurisdictional mandates. Cohesiveness is more than a happy feeling; it provides the ability to react uniformly to a crisis. The focus of an effective DevSecOps team should be to invest extensively in risk assessment, including exhaustive threat modeling, to understand its organization’s attack surface. Preparation is expensive, but being surprised costs a lot more.  Unplanned change isn’t easy The Project Management Institute’s (PMI) […]

Read More
Least Privilege Principles with Kiuwan in Romania

Putting the Principle of Least Privilege to Work for Web Apps

Noutați

With an ever-increasing proportion of day-to-day work on the desktop occurring in the form of web-based applications, organizations need to rethink how those applications work. They also need to examine – and in some cases tighten up – how web-based apps (or rather, the processes within which they operate) make use of privileges and access rights for Least Privilege. Let’s ponder this as we consider some basic definitions. Understanding the Principle of Least Privilege I’ve been writing about this principle since the early 2000s (the first edition of our Sybex CISSP Study Guide is copyright 2003; it’s now in its 6th edition). Simply put, the principle of least privilege means that no user, process, or program should have any more privileges than it absolutely needs to do its job. This principle exists to prevent cases where excessive (and unnecessary) privileges can lead to unwanted, unauthorized, and perhaps even damaging use of such privileges can occur. I just learned that this principle is sometimes abbreviated POLP, and takes the principle of minimal privilege (POMP) and the principle of least authority (POLA) as synonyms, thanks to Nate Lord’s excellent discussion at the Digital Guardian. POLP’s Security Implications for Web-based Apps Web-based apps generally run in two or more security contexts, in which one might be characterized as “typical user” and the other as “administrator.” Of course, some Web-based apps (think security portals, cloud or network management consoles, threat and vulnerability reporting and alerting tools, and so forth) may have multiple levels of administrative privilege. Thus, they can distinguish basic admins who maintain and update the runtime environment from senior admins who can install and configure the environment, establish role-based security structures and populate them with groups and accounts, and so forth. Across the board, asserting the principle of least privilege starts with checking the processes and accounts associated with a web app: Do ordinary users run in the typical user context? Do admins run in an appropriate administrator security context? If so, that’s one step in making sure things are working as they should be. If not, it’s time – right now! – to set things right and put accounts into their proper security contexts. But there’s more involved in asserting POLP for web-based apps. Using some kind of audit tool within the access control capabilities of the host platform’s OS, and the security tools for the web-based app itself, it’s essential to get as complete a picture of the privileges available to the web-based app itself (it’s usual runtime context, that is). Then, do likewise for the user accounts and/or groups or roles that are allowed to run this web-based app. Here, you’re looking for grants of access or privileges that exceed the bare minimum that’s needed for the item under consideration (be it user, group, role, process, or program). Of course, if you find anything, you’ll need to trim it back to where it should be. From a forensics and information-gathering perspective, you’ll also want to use logs or other audit tools to get a picture of how privilege is actually being used within the general runtime context for the web-based app as well. Settings that grant access rights or privileges tell you what should be going on within that runtime context. Examination of logs and other audit tools that record, analyze, and report on actual USE of […]

Read More
Kiuwan cybersecurity prediction in 2020

Kiuwan Cybersecurity Predictions for 2020

Noutați

Ransomware attacks will become more efficient The capital investment for a given ransomware attack is so low that this will continue to be a big and frequent deal in 2020 for cybersecurity. It’s probable that it will become easier and cost-effective to pay the ransom and get on with business, instead of fighting it. The requests will become “right-sized” as the “ransoming business” finds the sweet spot when it comes to the “price point” of their “clients”. Business owners should recognize that getting attacked in this way is not a matter of IF, but WHEN. They should prepare all necessary precautions so that when that bad day comes, there is an option of blowing out the system and doing a rebuild (Disaster Recovery or Business Continuity). Two-Factor Authentication Will Slowly Become Standard Though it has become standard and mandatory in the EU for certain types of payments over online retailers, two-factor authentication is far from being a widespread standard for cybersecurity. When it is offered only as an option, the hardest part is getting people to use it. However, as the general population becomes more and more aware of data protection, we predict that many will choose to adopt MFA to protect their assets. Artificial Intelligence (AI) is on its Way to Becoming a Key Player in Cybersecurity Though we still haven’t seen a fully AI-powered malicious attack, it is highly likely that the “bad guys” will do like all good businesses and take routine tasks (e.g. hacks that worked and are commoditized now) and push them into automation (if that isn’t already “business as usual”). The next stage is to begin to fold in ML/AI to target their efforts and increase efficiency. IS practitioners will be forced to step up their game (because of limited bodies, limited hours in a day, unlimited attackers and attacks with increasing sophistication) and get up every morning, look themselves in the mirror and (repeat after me): Work Smarter Not Harder. They will be forced to follow the lead of the hackers and take routine tasks off of human responders and assign those tasks to AI to help reduce the total noise in the system and bubble up the items of interest (insert segue here to rant about how 2020 will NOT be a year of increasing intelligence around Risk Management). Security Spending Will Keep On Increasing This one is almost a freebie, with the increase in tech and decrease of the barriers to entry for a given hacker, the other side (IS) must add more fuel to keep pace. IS people are in short supply, awareness is up, penalties exist (think about GDPR, CCPA, and about 50 others), barriers to entry for hackers are down. Spending on security is bound to increase exponentially in this year. Attacks on data will be more threatening than Cyberwar There has always been a cyberwar component (North Korea, Russia, Iran, FVEY, etc.) just as there is a space war component (killer satellites and satellite killers: India, China, US, etc.) – it is just that most of us don’t get wrapped up in that level of work. International Cyberwar was not so widespread as predicted; however, a lot happened with regards to disinformation and data manipulation. What we did see and will see more of in 2020 is […]

Read More
SAST Romania

Selectarea solutie SAST

Noutați

Odată cu creșterea companiei și creșterea numărului de dezvoltatori, verificarea „manual” a prezenței vulnerabilităților devine din ce în ce mai dificilă. Devine necesar implementarea soluțiii SAST – testarea statică de securitate a aplicațiilor (Static Application Security Testing). Cum să alegi SAST? Nici o simplă vulnerabilitate nu poate fi găsită folosind algoritmi primitivi. Astăzi pe piață există o mulțime de soluții SAST, atât comerciale, cât și gratuite. Cele mai populare dintre ele sunt AppScan de la IBM Security, Synopsys, Veracode, Inspector de aplicații, MicroFocus, Appercut, Checkmarks. Eficiența procesului de dezvoltare depinde de alegerea soluției. Principalele avantaje ale soluțiilor comercial sunt: Concentrare pe securitate: algoritmi specifici și baze de reguli mari. Asistență pentru multe limbaje de programare. Interfață ușor de utilizat. Disponibilitatea pluginurilor și API-ului. Disponibilitatea suportului tehnic pentru instrument. Instrumentele gratuite și interfețele web sunt adesea inferioare celor plătite, deoarece conțin algoritmi mai simpli, iar bazele regulilor sunt mai puțin complete. Sarcina lor principală este de a găsi erori în cod. Specializarea și funcționalitatea acestor soluții este de obicei foarte restrânsă. Odată selectată soluția SAST, trebuie să o integrați în procesul de dezvoltare. Opțiunile de integrare pot include: încorporarea unui repozitoriu, medii de dezvoltare, servere CI / CD, sisteme de urmărire a sarcinilor. Un instrument bun este capabil să se integreze cu succes în toate clasele de sisteme enumerate. Notă: API-ul SAST deschis include API-ul JSON și CLI și oferă oportunități ample pentru integrarea și automatizarea suplimentară. Pentru a selecta instrumentul care îndeplinește cel mai mult obiectivele și obiectivele dezvoltatorului, trebuie să efectuați compararea funcțională și compararea lor în calitate. O comparație funcțională se realizează în funcție de mai mulți parametri: ei analizează comoditatea interfeței și comoditatea integrării cu instrumentele proprii. În același timp, este important să efectuați verificări pe propriile coduri. Următorul pas este o comparație a calității: analizează vulnerabilitățile și falsele pozitive în raport cu propriul cod. Nuanțele și subtilitățile analizei de cod Cu cât se constată mai devreme o vulnerabilitate, cu atât este mai ieftin pentru dezvoltator și pentru client. Acest lucru înseamnă că produsul trebuie verificat periodic pentru vulnerabilități în timpul procesului de dezvoltare și, în plus, să efectueze verificări de control înainte de eliberare. Viteză și resurse: de obicei este de așteptat ca instrumentul să funcționeze rapid; alergați la fiecare schimbare; arată pe zbor cine și când a introdus vulnerabilitatea. De fapt, SAST analizează codul timp de cel puțin 8 ore, este dificil să îl executați la fiecare modificare; este dificil să identifici autorul vulnerabilității; fals pozitive se întâmplă. Deci, apare întrebarea: cum să configurați DevSecOps. Este foarte important să: Calculați timpul și resursele pentru a vă analiza codul. Identificați declanșatorii pentru începerea unei scanări pe baza rezultatelor. Rețineți că puterea va trebui recalculată periodic. Este mai bine să folosiți o analiză incrementală, dar aceasta trebuie făcută cu prudență, deoarece vulnerabilitățile pot fi pierdute. De exemplu, puteți rula testarea folosind SAST atunci când un dezvoltator trimite o sarcină pentru revizuire. De asemenea, puteți începe scanarea la sfârșitul zilei de lucru. O altă problemă este falsul pozitiv și obținerea de informații despre vulnerabilități multiple în raport. În acest caz, dezvoltatorul este recomandat: să filtreze analizatorii statici în funcție de vulnerabilități și de fișiere. Puteți exclude bibliotecile, analiza criticitatea, adăuga excepții pentru anumiți parametri. Este suficient să faci o astfel de lucrare o singură dată, pentru ca, în […]

Read More
kiuwan pentru analiza statică

Cum se utilizează corect analiza statică

SAST, Noutați

Acualmente se vorbește din ce în ce mai mult despre analiza statică pentru căutarea vulnerabilităților ca etapă necesară a procesului de dezvoltare. Cu toate acestea, mulți vorbesc și despre problemele analizei statice. Dacă ați încercat vreun instrument specializat, puteți fi înspăimântat de rapoarte lungi, cu recomandări confuze, dificultăți în configurarea instrumentului și falsuri pozitive. Deci este încă necesară analiza statică? Experiența sugerează că este necesar. Și multe dintre problemele care apar atunci când vă uitați prima dată la instrument, este destul de posibil să rezolvați. Voi încerca să vă spun ce poate face utilizatorul și cum ar trebui să fie analizatorul astfel încât utilizarea sa să fie utilă și să nu se introducă „un alt instrument inutil, de care are nevoie Security Officer”. Despre analiza statică Deci, am vorbit deja despre limitările teoretice ale analizei statice. De exemplu, analiza statică profundă încearcă să rezolve probleme care sunt exponențiale în complexitate. Prin urmare, fiecare instrument caută un compromis între timpul necesar, resursele cheltuite, numărul de vulnerabilități găsite și numărul de falsuri pozitive. De ce avem nevoie de analize aprofundate? Orice IDE găsește foarte repede erori, uneori chiar și legate de securitate – care sunt unele probleme exponențiale? Un exemplu clasic este SQL injection (și orice altă injecție, cum ar fi XSS, RCE și altele asemenea), care trece prin mai multe funcții (adică citirea datelor de la utilizator și executarea interogării apar în diferite funcții). Căutarea acestuia necesită o analiză interprocedurală a fluxului de date, iar aceasta este o sarcină de complexitate exponențială. De acord, fără a căuta astfel de vulnerabilități, analiza nu poate fi considerată profundă. Din același motiv, trebuie să analizați codul în întregime și nu în părți – altfel, vulnerabilitățile interprocedurale pot fi ratate. În ultimii ani, am acumulat multă experiență în comunicarea cu clienții (potențiali) ai diferiților analizoare statice. În special, discutăm revendicările la instrumente pe baza rezultatelor primei utilizări (pilot). Majoritatea revendicărilor urmează într-un fel sau altul din limitările teoretice ale tehnologiei. În plus, este posibil ca instrumentele să nu aibă pur și simplu funcționalitatea de care utilizatorul are nevoie. Cu toate acestea, în opinia noastră, analizatorii se pot deplasa (și se îndreaptă) către utilizator în ceea ce privește rezolvarea problemelor identificate mai jos. Dar, de asemenea, trebuie să poți folosi analizoare, nivelând consecințele acelorași probleme – după cum se dovedește, acest lucru nu este atât de dificil. Hai să mergem în ordine. Vă puteți imagina o situație de model: decideți să încercați tehnologia în acțiune sau să alegeți un analizor static – efectuați un pilot. Desigur, nu aveți încredere în cazurile de test ale furnizorului și doriți să încercați să analizați codul dvs. (în același timp puteți găsi vulnerabilități reale și să le remediați). Vi se oferă un program de instalare sau o mașină virtuală pre-configurată cu un sistem pentru o perioadă scurtă de timp. Începutul analizei Mai întâi trebuie să lansați analiza. Accesați interfață și totul pare clar: încărcați arhiva cu codul sursă și faceți clic pe „analiză”. Dar nu: primiți mai multe formulare cu câmpuri diferite care trebuie completate cumva. Este necesar să indicați limbaje de programare, unele setări ale analizorului, selectați pachete de vulnerabilitate (de unde știți ce este inclus în ele?) Ș.a. Treci acest test și începe analiza. Ah, nu – o eroare de scanare. „Formatul nu corespunde cerințelor”, „Este necesar un […]

Read More

Abonează-te la noutăți

Primiți noutăți și oferte despre SDLC tools

Close Menu