Network architecture and Networking in the Cloud

Migrating to the cloud can be a big project. Firstly, differentiating between application and general infrastructure. The general infrastructure will become what most call the 'Landing zone', the base of the infrastructure, what is needed before the migration of applications and services can start. Usually it is during the 'Landing zone' phase that the network infrastructure must be planned and created. Future growth and scalability must be kept in mind, bad planning of the network can lead to issues that are burdensome to fix in retrospect. There are many things to keep in mind and consider while trying to find the best solution.

Will the whole solution be in the cloud or should on premises services and cloud services be connected in a hybrid solution? What architecture is most suitable, and based on this, how should IP addresses be distributed? What is our future growth looking like, should we be more restrictive with IP addressing to be prepared for the future? What services will be used to ensure secure access and communication between users and services?  

The focus of this Academy Master Program (AMP) will be to try and simplify questions like these, and to prove the capabilities of Omegapoint in this subject. 

About the student

My name is Oskar Wijkström, I joined Omegapoint in 2022. Like most of our new recruits I joined Omegapoint's academy professional program. So, I have been at OP for 2 years now, the time really flies. I have worked in the financial sector as a backend development at Swedbank, and more recently I helped develop a Kubernetes platform for a private cloud platform. 

Now I am dedicating most of my time to the cloud, focusing on AWS. Where I try to learn all that I can in subjects such as networking, architecture and infrastructure. 

Goals

Networking is a subject that most developers have stumbled upon, but such issues are in many cases just sent to a network administrator and solved for you. But when migrating and working in the cloud it can be great knowledge to have. Therefore, a big goal of this AMP is to try and simplify this migration, increase the knowledge internally at Omegapoint and to show how interesting and fun it can be to work with. Collect the most essential information and present it in the easiest way possible and simplify answering questions such as: 

• What is the current best practice and why is it so?

• What is the best solution for some of the most common projects

• What alternatives are there? 

To achieve this, Blueprints will be created to be used for new projects, scaling existing and general development in the cloud. Presentations on advanced and interesting topics will be held, to increase general knowledge at Omegapoint.

A presentation will be held at LoKoKo this fall, covering how to set up a Wide Area Network (WAN) in the cloud, the benefits of it and how it compares to other solutions.

Currently Omegapoint is a Security Competency Partner of AWS and seeks to deepen that partnership by becoming Networking Competency Partners. Thus, a taskforce will be created so Omegapoint can apply to also become Networking Competency Partners. 

Securing AKS applications

Building and deploying serverless applications has become a commodity in today’s cloud landscape. There are plenty of architectural patterns to choose from when designing software. When it comes to choosing a pattern that scales well, is portable between platforms, and is widely adopted, Kubernetes is a popular choice for orchestrating containerised applications. This will be at the core of my Academy Master’s Program (AMP) project.

Who am I?

My name is Silvan Zeller and I have been working at Omegapoint for almost five years now. After writing my master’s thesis here I completed the APP trainee program within information security and have worked on a variety of different projects since then. I have worked with privileged account management for different customers and then went over to assist in developing a serverless application for a customer in the fintech sector. As of now, I am a part of a team at Omegapoint responsible for developing a Kubernetes platform for a private cloud solution. With that said, I believe it might be time to delve deeper into the technical details.

About Kubernetes

Kubernetes is a framework originally developed at Google that manages services and workloads, from scheduling, scaling, networking, supervision, and administration. Organizations can choose to set up a self-hosted platform or run on a managed platform. Each of the established cloud service providers (Azure, AWS, Google Cloud, etc.) provide a Platform-as-a-Service (PaaS) offering for Kubernetes workloads. Maintaining such a platform requires substantial effort and according to the shared responsibility model, security concerns can be offloaded to the cloud service provider of choice by choosing a PaaS deployment model.

Shared resposibility model according to Microsoft

My Goals

In my AMP project I am attempting to shed light on the question, how does one go about securing applications that run on a managed Kubernetes platform? More specifically, I chose to investigate concrete measures to take on Microsoft’s Azure Kubernetes Platform (AKS). There are a lot of security and hardening guidelines available online, such as Azure’s security guidelines, tutorials on Kubernetes or the OWASP Kubernetes Top 10. However, these guidelines are sometimes a bit vague or only cover a specific security aspect. I believe that a compilation of concrete security measures would surely come in handy. In my work, I will provide practical and applicable security guidelines using a simple example application covering the following aspects:

• Securing cluster ingress to applications

• Securing egress from cluster to external services

• Access control to the Kubernetes cluster

• Container / pod security

• CI/CD pipeline security

• Logging and monitoring

My goal is to provide a blueprint for architects, security experts, and developers to use when designing and developing applications. So far, I have produced a tutorial on securing ingress to applications using Application Gateway and held a presentation on that topic during this year’s OPIgnite Peer-to-Peer conference, one of Omegapoint’s internal conference which is aimed att experts within Azure.

Ingress to AKS with Application Gateway and Ingress Controller with Azure Key Vault

I am publishing all tutorials on Omegapoint’s private GitHub account which can be found in the secure-kubernetes-aks repository and will continue to hold workshops and presentations on competence days as well as our internal conferences. As the coverage increases, I will publish the lessons learned as a course on Omegapoint’s Learning Management System (LMS) with the hope of enabling a better security posture for Kubernetes applications running on AKS and further improving my knowledge within Kubernetes, AKS, and its security on the way.

Luckily, I am not on my own in this endeavor. My colleague Olle Mulmo is my mentor in this project and is helping me with all his experience within cloud and security.

Assurance by Automation and AI

Assurance is a term used when talking about security in software development. There are different definitions of the term, and I am summarizing the content of the definitions as; The degree of confidence that the security needs of a system are satisfied.

Today, to feel confident that the security needs of a system are satisfied, a lot of manual work is needed. Spread sheets and checklist are typically used, which usually provide samples of the current state of the system. But what if we could automate some of the manual work? And what if we could provide information about the system in real time?

My name is Linnéa Oxenwaldt, and I have been working at Omegapoint for almost 3 years where I have worked with facilitating the implementation of security in the software development lifecycle. Since September 2022 I have been a part of the initiative CyDig (cybersecure digitalization), which aims for automating assurance and improving the security state by visualizing the security needs of systems. I am now doing my AMP (Academy Master Program) where I will continue the work with expanding the assurance controls contained in CyDig and increasing their value. I will also investigate if AI could be of use when implementing assurance controls. By my side during my AMP, I have my mentor Nada Kapidzic Cicovic.

CyDig

The project CyDig started as a result of reading the book Investments Unlimited which describes how a financial company builds and implements automated assurance controls in order to get view of the security state of their systems. By visualizing the result of the controls, they knew what was needed to be done to satisfy the security needs.

CyDig is a set of controls that runs in a pipeline, which then uploads the result to a dashboard. The controls is in the set of quantitative assurance, described in an earlier post. A view of a team’s dashboard can be seen below where the result of the controls is either on a team level or on a code repository level. The result of the controls is evaluated together with a set of requirements, and if the security need is met or not is shown by different colors.

During my AMP I will try to identify new controls that are technically implementable to increase the level of confidence that system security needs are fulfilled. I will go through some regulations (e.g. Cyber Resilience Act) to identify security requirements and pair them with existing or new assurance controls.

AI and Assurance

AI is an uprising field where a lot is happening today and will continue to happen the coming years. We can already see that things we were doing manually yesterday, AI can do automatically for us today. I will during my AMP investigate how AI can help us do some of the work that is needed to fulfill our security needs. Can AI do threat modeling? Can AI do code reviews? Can AI review external components? And can we use AI as an assurance tool? These are some questions I will try to have answers to.

My Goal

My overall goal can be summarized as: Increase the assurance level in the software development lifecycle. In other words, help development teams and stakeholders to have confidence that the security needs of their systems are satisfied.

The main activities that will take me to the goal are:

• Expand and improve the quantitative assurance model (CyDig).

• Improve competence about how AI can be helpful when working with security and assurance.

• Spread the knowledge about assurance, and the combination of secure development and AI.

I hope that I can contribute to a world where it is fun and easy to achieve secure by design!

Securing the agile development lifecycle

The use of agile development methodologies is very popular due to its ability to deliver software quickly and efficiently. However, with this increase in speed, there is a risk of compromising security. This is where Omegapoint should shine, mixing the agile philosophy with our knowledge of application security.

We all know it is important to integrate security practices into the agile development lifecycle. One way to achieve this is by following the CIS (Center for Internet Security) v8 controls. These controls are a set of best current practices that organizations can use to improve their security posture. Omegapoint has interpreted the CIS controls and summarized efforts that can be taken by teams working with cloud-native applications to implement the CIS controls. These efforts are the basis for the security review conducted as a service by Omegapoint Gothenburg.

In this blog post, I will discuss how all this corresponds to my AMP (Academy Master Program) project and how we as a company secure our development lifecycle and consequently the code we are developing, maintaining, and operating.

Quantitative assurance

There have been many successful initiatives regarding software security in Omegapoint’s history. Right now, there is work being done in compliance-as-code (as described in an earlier post) as well as Cydig’s work on automated controls that proves that we practice what we preach regarding security-related controls. Both these initiatives will enhance the security of our products by forcing best practices to be used. These checks are part of the quantitative assurance in Omegapoint’s new delivery model.

Qualitative assurance

The qualitative assurance part of Omegapoint’s delivery model is more about the “soft” parts of good practices. This is where my AMP project comes into play. I will concentrate on the “softer” parts of a secure development lifecycle. My main goal is to document a set of questions which can be used to assess if a development team follows the CIS v8 security-related controls. Omegapoint development teams should be able to use these questions to self-assess their security posture and the questions should also be used when assessing the development teams at our clients. The questions should be based on the work already conducted by Omegapoint regarding the CIS controls, while also drawing from the extensive experience our colleagues have regarding secure software development.

I am not alone.

I will not be alone on this journey. To help me are my two mentors, Tobias Ahnoff and Martin Altenstedt, as well as my fellow AMP students and their corresponding mentors. With the help of these competent colleagues, I believe this project will be extremely educational for me and will hopefully accelerate my knowledge of application security.

Bidrag till Omegapoints leveransförmåga genom ”Design Patterns as a First Line of Defence”

Den nya konsulten på uppdraget vill visa vad hon går för. Den nya kunden har höga förväntningar. I ett nytt åtagande är det viktigt att leverera värde från start.

Hallå där! Vad kul att du hittade hit! Jag heter Adam och jag började min resa här på Omegapoint år 2019 som en del av Academy Professional Program (APP). Snabbspolar vi tre år, under vilka jag jobbade med ett av våra större åtaganden, har jag nu fått möjligheten att bredda min kompetens genom att vara en del av Academy Master Program (AMP). Det känns som en unik möjlighet och jag ser fram emot att fortsätta utveckla mig själv och vårt företag tillsammans med det fantastiska AMP-gänget! 

Design Patterns as a First Line of Defence

Så vad är "Design Patterns as a First Line of Defence" kanske ni undrar?  

Vi på Omegapoint är experter inom våra områden och jag vill bidra med att vi tar hjälp av varandras expertis på ett effektivt sätt. Mitt mål är att skapa ett underlag till kundåtaganden så att vi snabbt kan bygga upp en anpassningsbar och säker lösning som är baserad på beprövade koncept som vi vet kommer att fungera.  

Azure är en av de mest populära molntjänsterna på marknaden idag, och det finns en stor efterfrågan på att bygga säkra molnapplikationer som är skalbara och lätta att underhålla. Som en del av mitt Academy Master Program har jag fördjupat mig inom just Azure. Jag har åtagit mig att utveckla en katalog med designmönster för hur man kan konfigurera sin Azure miljö på ett enkelt och säkert sätt. Katalogen kan bli användbar för kundåtaganden där vi vill säkerställa en hög nivå av säkerhet för kundens tjänster och jag har valt att kalla den för Design Patterns as a First Line of Defence.

När jag själv var en del av Omegapoints större åtaganden hade en sådan katalog varit till stor hjälp, inte bara för kunskapsspridning men också för att snabba på leveransen till kunden.  

Katalogens innehåll

Ni kanske undrar vad man kan förvänta sig från katalogen. Här kommer ett axplock på vad den kommer att innehålla: 

• Hur man kan integrera sin CI/CD med OpenId connect från GitHub. OpenId Connect möjliggör för din byggpipa att få rätt tillgång till dina Azure resurser, utan att behöva lagra långvarande hemligheter. 

• Hur man kan säkerställa att endast auktoriserade personer och tjänster har tillgång till tjänster med hjälp av rollbaserad åtkomstkontroll (RBAC) i Azure Active Directory (AAD).  

• Hur man kan sätta upp en miljö som är helt rollbaserad för att bli av med beroendet att lagra hemligheter i exempelvis Azure Key Vault. 

• Infrastrukturkod i form av Azure bicep. 

• Backend kod i .NET 6 (C#) som följer Secure by Design principerna.  

…och mer därtill!  

Avgränsning

Jag har valt att avgränsa mitt arbete till en mikrotjänstarkitektur i Azure med .NET som backend. Tänk cloud native, serverless och least-priviliged så tror jag man kan uppskatta omfattningen av vad katalogen kommer att innehålla. Min förhoppning är att mitt arbete kan ge inspiration till en liknande katalog i en annan tech-stack i framtiden! 

Skiftat fokus 

Till en början var mitt fokus riktat mot designmönster i kod eftersom jag främst arbetat med backend-utveckling och ville spetsa min kompetens inom det. Men efter diskussioner med AMP-gänget och andra intressenter har fokuset skiftat mer till designmönster i molnet. Jag känner att det var rätt beslut och att jag har landat i något som både kommer att utveckla mig själv och samtidigt ge värde till Omegapoint! 

AMP + OT = sant

Hej bloggen! Chanelle heter jag och har jobbat som OT-/informationssäkerhetskonsult här på Omegapoint i lite mer än ett år nu. Jag är då en del av den fjärde årskullen av Academy Master Program (AMP) och får därmed äran att skriva lite inlägg här på sidan.

Mitt fokus är OT-säkerhet, där OT står för Operational Technology. OT är likt IT ett samlingsbegrepp för många olika typer av system, komponenter och så vidare, med den enda (och rätt stora) skillnaden att det har ett industrifokus jämfört med de mer traditionella IT-systemen som har ett tydligare affärsfokus. OT-system består av hård- och mjukvara som interagerar med och övervakar den fysiska industriella miljön, i form av infrastruktur, processer och enheter, i realtid. Denna hård- och mjukvara upptäcker förändringar genom den ständiga övervakningen av miljön och kan därmed skapa förändringar i processer direkt när det behövs.

Kort och gott är OT ett samlingsbegrepp som inkluderar industriell infrastruktur och alla dess underliggande nätverk, system och komponenter. OT-säkerhet syftar därmed på att säkra upp dessa typer av miljöer, där digitala intrång kan ge fysiska skador.

Jag sökte till AMP för att jag ville ha möjligheten att fördjupa mig inom OT-säkerhet då det är ett område som först och främst är väldigt aktuellt med tanke på omvärldsläget då det är dessa typer av system som ofta är måltavlor för angrepp, exempelvis genom ransomware. Den ökade digitaliseringen ställer också till det lite för dessa typer av system som ofta är väldigt gamla och länge varit helt isolerade från Internet. Dessutom är OT ett relativt nytt och outforskat område för många (delvis inkluderat mig själv), så jag vill bredda på både min och andras kompetens kring just detta!

Mitt mål med AMP och vägen dit

Mitt mål med AMP kan man dela in i två delmål. För det första vill jag bidra till att OT-system blir säkrare så att de kan klara av dagens säkerhetsutmaningar i en osäker och alltmer digitaliserad omvärld. Jag ämnar därför att ta fram ett underlag med OT-säkerhetsåtgärder i en mer kortfattad form som kan användas likt en checklista för att kontrollera att systemen och nätverken svarar upp mot de krav som bör uppfyllas baserat på existerande direktiv, standarder, ramverk och så vidare. Tanken är också att inkludera förslag på implementation för vardera säkerhetsåtgärd så att brister kan åtgärdas på ett enklare sätt.

För det andra så vill jag gärna bidra till att allt fler får upp ögonen för OT och allt vad det innebär. Därför ämnar jag att hålla kontinuerliga pass på kompetensdagarna där fokus kommer vara mer på de organisatoriska aspekterna av OT på en grundläggande nivå, så att så många som möjligt kan delta och förhoppningsvis lära sig något nytt.

För att uppnå mina två delmål finns det en hel del aktiviteter för mig att genomföra, exempelvis:

• En förstudie där existerande publikationer identifieras och analyseras, inkluderat här är exempelvis det nya NIS2-direktivet samt vägledningar och standarder inom området.

• Deltagande på konferenser, seminarium, webinarium, etc., både för kompetensutveckling samt nätverkande med branschkollegor.

• Samarbete med OP-kollegor och kollegor på mitt externa uppdrag så att jag får både bollplank och granskare av mitt material.

• Fördjupa mina kunskaper om OT-säkerhet genom att kontinuerligt hålla mig uppdaterad om vad som händer och sker, samt kika på att kanske ta en OT-specifik certifiering.

Avslutningsvis

Jag tror och hoppas att min tid som AMP-student kommer vara givande och utvecklande. Jag har en känsla av att jag kommer lära mig en hel del och ser fram emot vad som komma skall!

The DevOps loop and "Release on Demand"

Updated version and translated into English

The DevOps loop

If you were to google "devops loop", the majority of hits would most likely be different version of the following image:

The idea of the DevOps loop is to describe the development lifecycle as an infinite loop, from planning to production via feedback then back to planning and so on. You probably never reflect about each individual step in the loop but rather think they are descriptive and in the correct order.

In the work I do with spreading the gospel of secure development I often use the DevOps loop as a tool to illustrate how to add activities related to security into the development lifecycle:

• In “Plan” we work with C-I-A and Privacy-requirements, and perform threat modeling.

• In “Code” we work with pull-request/peer-review.

• In “Build” we scan for the use of known vulnerable external components (SCA) and use static code analysis (SAST) in our build pipeline.

• In “Test” we work with security related test cases, maybe derived from a penetration test, with the intent of “how do we prevent this from happening again”.

You get the idea. But when we look at “Release” and “Deploy”, for me it gets problematic. Maybe not so much with mapping activities, but does the “Release” step really come prior to “Deploy” in a modern development lifecycle?

Release on demand

Out of curiosity for SAFe (Scaled Agile Framework), I participated in a "Leading SAFe" training during spring 2020 and there we talked about "Release on Demand" in the section where they describe how to "Build a Continuous Delivery Pipeline with DevOps". The idea with "Release on Demand" is to separate "deploy to production" from "release" so that the value of what you do is made available when needed.

“Release on Demand - Making value available when it's needed”

In the DevOps loop used in the training material, the order of the “Release” and “Deploy” steps was reversed:

and suddenly the initial callenge I had with the ordering of the “Release” and “Deploy” steps is gone.

• In “Deploy” we move new functionality into the production environment but it is not yet made available to customers, rather hidden behind feature flags, or we use canary releases to test the new functionality on a limited amount of users initially.

• In “Release” we make the new functionality available to all customers when the timing is right. Maybe immediately or at a strategically better moment later on.

The new ordering of the steps in the DevOps loop suddenly feels spot on to me.

But why is the incorrect order still dominating in images you find when googling?

It is probably related to how software delivery looked like when the loop was initially created (around 2009). Much of software was “Released” and packaged and then delivered to customers and “Deployed” into their environment. This was before the majority of software was delivered as web based solutions and SaaS became the dominant way of buying software. I also think that people hasn’t put that much thought into if the order of Release and Deploy (as maybe I have).

So to wrap up, I present the correct version of the DevOps loop with a couple of security related activities mapped out:

The “correct” DevOps loop with examples of security related activities in each step

/Mats Persson - Security consultant at Omegapoint, Mats LinkedIn profile - 2023-01-02

Låt oss tala om PageRank och link building inom SEO

Vad är SEO? 🤖

Webben som ni vet är en egen värld i sig och SEO är en del av den världen. Akronymen SEO står för Search Engine Optimization. Men vad är det? Jo, varje gång du använder Google eller Yahoo (eller vilken söktjänst som helst) för att söka fram något så använder du dig av deras sökmotorer, och dessa sökmotorer använder sig av algoritmer för att söka igenom hela webben för att hitta det som matchar det du sökte efter. Algoritmerna i sig använder sig av ‘crawlers’, ‘indexering’ & ‘rankning’ för att göra denna analys.

Crawlers, indexering & ranking

Crawlers är i princip bottar som skickas ut av sökmotorer för att spana vilka hemsidor som finns, för att sedan samla information om dem. Om det kommer ytterligare information kring en hemsida som redan finns i deras lista så uppdaterar de den informationen. Crawlers hoppar från länk till länk, så om man har en ‘dold’ länk som det inte finns en koppling till från någon annanstans i en hemsida så blir det svårt för crawlers att kunna spara ner information om den länken.

Den information som samlas in av crawlers kommer sedan att indexeras. Värt att notera är att informationen samlas inte bara för att, utan det finns även algoritmer för att kolla kvaliteten på innehållet. Om man har repeterat innehåll, innehåll som ser ut att vara spam, har duplicerade länkar, eller som nämndes ovan att crawlern inte kunde nå innehållet så finns det en risk för att hemsidan och dess innehåll inte indexeras.

Genom att ha bra och relevant innehåll kan man pusha för bättre rankning. Skriver du in pannkaksrecept i sökfältet så är det resultatet av crawlers indexering av de hemsidor med mest relevant information som visas som toppresultat. Detta kallas även för organisk trafik, dvs den trafiken som naturligt lockar en användare till en hemsida. Ett annat alternativ är köpt trafik. Det är den organiska trafiken man önskar förbättra, eftersom köpt trafik är mer eller mindre reklam eller att man ‘köper’ vissa sökord. Det man gör är att man betalar en viss summa för ett ord/fras och då visas man överst när någon söker på det ordet/fraset. Kortfattat kan man säga att ju högre rank, desto bättre chans har man att hamna överst på listan av användarens sökresultat.

(Ibland kommer reklam länkar först, men det är lite separat från detta, så jag kommer inte gå in på det.)

Okej nu vet jag om SEO, vad är PageRank? 📈

Inom traditionell SEO finns det en algoritm som kallas PageRank och denna algoritm används av Google för att rangordna resultatet av sökmotorn. Det är en av flera algoritmer som används för att t.ex. mäta vikten av en hemsida. Algoritmen mäter antalet seriösa hemsidor (vi kommer till detta senare) som länkar till en hemsida och detta ska då estimera hur viktig den sidan är.

Så det innebär alltså att om ett antal hemsidor (de lila bubblorna) länkar till en hemsida B (den röda bubblan) så kommer hemsida B’s SEO index att förstärkas och därmed få större vikt och ev. leda till bättre index-värde.

Bild från Wikipedia

Ett exempel på en röd hemsida skulle vara en officiell myndighetssida, t.ex. Krisinformation.se. Massvis med hemsidor runtom Sverige länkar till Krisinformation.se när det kommer till nyheter kring restriktioner etc, det gör att den blåser upp enormt. Men vad händer med hemsida C (den oranga bubblan)? Den är nästan lika stor som hemsida B, dessutom är det hemsida B’s enda länkning. Eftersom hemsida B har fått ett bra rykte och har en trovärdighet så kan den lyfta upp hemsida C. Eftersom algoritmen förlitar sig på Krisinformation.se kredibilitet så antar den att de inte skulle länka till vilken hemsida som helst så därför är hemsida C förmodligen lika pålitlig och viktig.

Nu till det roliga, link building 🔗

Som allt annat inom web finns det white hat & black hat:ers inom SEO. White hat SEO är optimering för att förbättra upplevelsen för användaren av dessa hemsidor, målet är att skapa hemsidor av kvalité som uppfyller användarens syfte med att besöka hemsidan. Black hat SEO är optimering är för att tillfredsställa bottarna. Ett sätt att göra det är att försöka manipulera PageRank, genom att få flera av ens egna låtsas hemsidor (det är hemsidor med oseriös innehåll skapad för endast ett syfte) att peka mot en specifik hemsida som man vill lyfta fram. Det finns tjänster som erbjuder detta, anlitar man dem så köper de upp domäner och slänger upp massvis med exempelvis Wordpress hemsidor (för att efterlikna de lila bubblorna ovan) och kan då snabbt leverera en SEO förstärkning.

Som jag nämnde så är inte PageRank längre den enda algoritmen som Google använder för att hantera indexering & rankning, så man kommer inte så långt med detta längre. Trots att detta inte är olagligt så gillar inte Google det alls, och upptäcker de att man har försökt fuska sig till ett SEO rank så blir man snabbt straffad (i form av förlorad Google listning) och alla hemsidor som länkade till den straffade hemsidan blir också straffade. Riktigt maffia-beteende, som att de kommer efter dig och alla i din familj.

Detta hände det amerikanska klädesmärke företaget JC Penny, de gick från att dyka upp först när en användare sökte på ordet ‘tröja’ eller ‘klänning’ vilket är väldigt populära sökord så självklart är slaget om första plats stort och komplicerat (och ibland dyrt), till att hamna på Googles 78:e sida. Det kan var lite farligt för de företag vars hela affär snurrar kring t.ex. online-shopping, man kan förlora enorma mängder med pengar när man förlorar sin rankning. (Här kan du läsa mer om skandalen).

Detta kan vridas ännu mer och användas som sabotage. Nu när man vet att Google straffar så hårt, varför inte anlita en sådan tjänst för att skapa låtsas hemsidor för att senare peka mot en konkurrents hemsida. Det kan kännas lockande att putta bort konkurrenten och se till att ens egna hemsida hamnar överst. Det är tyvärr inte ovanligt.

Det där lät lite läskigt, vad gör man om man skulle bli straffad av Google? 🤔

Kom ihåg, precis som allt annat så är det är du, eller ditt företag, som har ansvar över din produkt eller din hemsida och därmed hemsidans SEO. Upptäcker man att hemsidan har kopplingar till dåliga/oseriösa hemsidor finns det några sätt man kan gå tillväga för att hantera situationen.

1. Försök kontakta ägarna till dessa hemsidor som länkar till din hemsida och be dem ta ner länkningen.

2. Använd Google Disavow Links för att kontakta Google direkt för att säga att “dessa länkningar var inte avsiktligen kopplade. Räkna inte med dem när ni evaluerar min hemsida.” Anledningen till att det här alternativet inte är på plats nummer ett, är att Google tar sin tid för att undersöka och verifiera att det du säger stämmer, och i.o.m att verifikationen tar tid så vill de att du i första hand försöker lösa problemet själv.

3. Om du har behov av att på flera ställen länka till andra hemsidor, men inte förebygga från att verka som en oseriös hemsida eller försöker förstärka andra hemsidor kan du använd `rel="nofollow"` i dina länkar .

Visst var det här kul?

Så nu vet vi lite om SEO och PageRank inom Google. Andra sökmotorer som Yahoo och Bing har också algoritmer som de förlitar sig på för att sköta vilket resultat som sökmotorn ska visa först. Men Google är störst, så därför fokusera jag på dem.

Det viktigaste att komma ihåg är att Google kan vara snabba på att straffa, men ta flera månader innan du får tillbaka din SEO ranking, så se till att hålla koll på din hemsida.

Link building är såklart inte det enda sättet en SEO black hat:are skulle vilja/försöka för att manipulera för bättre SEO, utan några andra kända metoder är:

• Keyword stuffing: att man fyller hemsidan med nyckelord som egentligen är irrelevanta för din hemsida, men de är ‘populära’ så man lägger till dem ändå.

• Invisible Text: Lite som ovan, man anger irrelevanta sökord eller kod i som ‘osynligt’ (för användaren) text, men som kan fångas upp av crawlers.

• Page Swapping: Här bygger man upp hemsidor som har bra innehåll och SEO, sedan byter man ut innehållet mot något annat. Resultat man vill uppnå här är att skapa flera hemsidor som har ‘bra’ SEO-ranking, för att kunna sedan kunna sälja vidare.

Vill du veta mer om SEO finns Googles SEO startup guide, eller allmänna SEO-nyheter på Search engine land.

AMP: Högintensiv träning för en tech lead wannabe


Idag har jag jobbat nästan exakt 3.5 år på Omegapoint. Det är ändå ett slag! Jag trivs och älskar alla möjligheter man får att bli en mer skärpt systemutvecklare. Som AMP, vilket tillåter mig att boosta mig själv och förkovra mig själv i det jag brinner lite extra för. Och vad är det? Jo! Jag vill förstå bättre hur vi kan gå från att vara featurefokuserade och undvika ge oss själva onödigt mycket teknisk skuld eller för stora säkerhetshål.

Det är ju så himla lätt att man blir jätteduktig på att leverera feature efter feature men jag upplever att man ofta glömmer bort (eller kanske oftare: inte hinner med) allt det andra runtomkring, som säkerhet, hållbarhet, relevans! Eller så har man fått ärva något som är stort, komplext, och väldigt trassligt. I de lite sämre fallen står man och försöker hålla ihop ett jengatorn.

Mitt mål med AMP

…är lite floskigt ”att få nackmuskler nog att kunna lyfta blicken från features, till att kunna se helheten. Bygga självförtroende och bredda kunskap om arkitektur och säkerhet för att kunna leda team från featurefokus till att vara fokuserade team”.

Ibland har jag hamnat på djupt vatten och, även om jag alltid har kunnat anropa moderskeppet för stöd och hjälp så är jag… bekymrad över featurefokandet på bekostnad av bra arkitektur och säkerhet.

Hur många gånger har inte du, som läser det här, gjort en feature som ingen använder? Fått lappa ihop kod som lappar ihop annan kod? Tänkt “det är ingen annan som verkar bry sig, kan inte vara så farligt?” om ett litet säkerhetshål? Eller fått nya feature-förfrågningar från trettioelva olika håll, och du vet inte var du ska ta vägen?!

En första rot till problemet är att det ofta saknas ett tydligt tekniskt ledarskap. Och då kände jag att gud vad bra med AMP, så kan jag kanske accelera min kompetens, bygga på mina gains och vara den som direkt bidrar med ett tekniskt ledarskap istället för att leverera den som en proxy! Kanske till och med bli så muskulös att jag kan lyfta andra?

Vägen till mitt mål

Inte en helt uttömmande plan men kort:

- Lära mig mer om ledarskap och agila metoder

- Leda ett case eller på annat sätt vara mini-teamlead i kontrollerade former

- Ha ett uppdrag där saker inte är för tillrättalagda (övning ger färdighet)

- Lära mig mer om molnet (ta om möjligt ett par cert)

- Lära mig mer om applikationssäkerhet och arkitektur

Min strategi handlar om att få bredd. Det är inte min mening att jag ska bli bäst på allt, men tillräckligt kunnig att kunna driva resonemang med team-medlemmar med både teknisk och affärsmässig spets, för att trovärdigt kunna väga för- och nackdelar med teamets vägval.

Och en hel radda mer saker, men de får ni höra om lite längre fram. För nu får det här lilla inlägget vara klart, innan det blir en hel novell.

Väl mött!

AMP - Ett avslut med en ny början

Jag började min AMP resa cirka 18 månader sedan med detta blogginlägg. Ambitionen var att försöka sätta ihop en ny modell för att bedöma företags och teams tekniska mognad, i syfte att i bästa fall förbättra Omegapoints bedömningar, sprida kunskapen om vad vi bedömer inom företaget och själv bli väldigt bra på att genomföra sådana granskningar.

Under resans gång har jag lärt mig mycket:

• Att mognadsbedömning är ett sämre ord än förmågeuppskattning - det känns som en mer positiv upplevelse för den granskade.

• Att det går att balansera ett tidvis intensivt uppdrag, ett kompetensutvecklingsprogram och bröllopsplanering. Det är bara väldigt svårt och man måste lära sig att säga nej.

• Att man bör optimera för att minska ledtiden för arbete från idé till produktion

• Att ovanstående mätvärde lider av att allokera alla resurser (såsom i människor) till 100%, gör mindre och få ut mer är det något motsägelsefulla mantrat

• Att om man har en grupp som godkänner releaser så går det långsammare att få ut i produktion men man får ingen höjd kvalitet i utbyte, den blir snarare ofta lidande

• Samt en väldans massa mer om DevOps-rörelsen, säkerhet, team, process och organisation

Jag har gjort min “mognadsmodell” eller förmågemodell som den fick heta till slut. Den är inte perfekt än och under AMP har antalet förmågor fluktuerat mellan ett tjugotal och ett hundratal till att till slut landa på en kanske något hög siffra om 29 förmågor man som IT-organisation bör tillskansa sig i liten eller stor omfattning för att kunna leverera värde ofta, snabbt och säkert. Modellen har provkörts på tre intet ont anande kollegor i intervjuformat och tog i anspråk mellan tre och sex timmar. Modellen har på så vis gått igenom ett par iterationer och hamnat på en nivå där jag själv tycker den är ganska bra. Helst vill jag ju att den skulle vara perfekt vid det här laget, men det behövs nog ännu ett par iterationer internt innan jag vill släppa lös den i det vilda.

Modellen i sig blev av kvalitativ typ. En mer kvantitativ modell hade behövt vara mer deterministisk, med många tydliga frågor så att man kunde beräkna en slutgiltig poäng över hur bra en organisation är. Jag var länge nere i den fällan att jag ville få det att fungera, men verkligheten är lite för komplex. Vilka förmågor en organisation behöver beror på bransch, vilken lagstiftning man lyder under och i vilken fas bolaget är i (exvis startup, scaleup, established). En kvantitativ modell skulle nog kunna ha sin plats, man vill ju gärna kunna mäta sig och jämföra med andra, men det kräver väldigt mycket utveckling och underhåll. Istället blir det intervjuformat där frågeställaren får använda sin erfarenhet för att borra djupare i svaga delar och sålla bort det som är irrelevant för just denna kund. Efter det får kunden tips om vilka förmågor man borde satsa på härnäst tillsammans med förslag på hur man kan mäta hur väl man uppfyller just den förmågan. Kunden får då ett verktyg för att benchmarka mot sig själv istället, som jag tror blir mycket mer givande och relevant.

Nu när AMP snart är färdigt hoppas jag kunna fortsätta utveckla min förmågemodell samt få nya och gamla förmågor att bidra till den så att den slutar vara “Adams modell” och börjar bli något hela bolaget kan stå bakom.

AMP med fokus på Compliance-as-Code

Mitt namn är Emelie Ohlson och jag har arbetat på Omegapoint sedan december 2021 och påbörjade mitt AMP (Academy Master Program) program i januari 2022. AMP ingick som en del av min rekrytering och tyckte att det var väldigt kul, spännande och givande att få studera ett fokusområde under min anställning i 1,5år. AMP bidrar inte bara till min egen kompetensutveckling med även kompetensutveckling internt hos Omegapoint och även kunna erbjuda våra kunder mer och bättre säkerhetslösningar i publika molnet. 

I mitt AMP program fokuserar jag på Compliance-as-Code som kan beskrivas som ”codification of compliance controls”. Mitt mål är ”modern information security through compliance-as-code”, vilket innebär att jag kommer ta fram tekniska templates och artifakter som säkerställer compliance i publika molntjänster och hur CasC säkerställer efterlevnad av lagstiftningar. Exempelvis att den operativa risken minskar vid användning av CasC – där denna inte får öka i samband med molntjänster.

Varför compliance-as-code?

Jag har genom tidigare arbetat väldigt mycket med IT-säkerhet mot molntjänster och genom detta arbete stött på många utmaningar för compliance att fungera, exempelvis Schrems-II och GDPR. Men också utmaningar kring hur tidskrävande och hur mycket resurser det krävs för att säkerställ att något är compliant enligt 100000x regler. 

Genom detta har jag fått en god relation med compliance vilket har resulterat att jag har ett ben i compliance, lagstiftning, risk och regelverk medan andra benet står kvar i tekniken och IT-säkerheten.

Mitt mål med AMP

Compliance-as-code har idag väldefinierade fördelar, där en gemensam standard skapas över hela IT-ekosystemet. Compliance-as-code är det moderna sättet att arbeta med informationssäkerhet och efterlevnad som gör det möjligt att flytta infrastruktur och applikation till det offentliga molnet, med ett säkerhetstänkande. Även om fördelarna är många är det få företag som lyckas med efterlevnad när de går mot det offentliga molnet.

Hur kan vi hjälpa och stödja företag och organisationer att lyckas med efterlevnad och övergång till det offentliga molnet? Med compliance-as-code as-a-service-erbjudande genom kurser och kompetensutveckling, tekniska templates och artefakter tillsammans med efterlevnads- och säkerhetskrav, och expertkonsulter.

114 krav är för mycket för att komma igång, 5-10 krav kan vara tillräckligt bra för att starta resan mot det publika molnet. Börja enkelt och molnbaserat!

Vägen dit

För att nå mitt huvudmål så har jag flertalet delmål som jag arbetar utefter där jag just nu fokuserar på:

• Certifiering AZ-900

• Certifiering AZ-500

• Utveckling av compliance templates – fokusområde Schrems-II

Stay tuned så får ni följa med på min resa!

AMP - 3:e årskullen är igång

Academy Master Program är nu inne på sin tredje årskull och i höstas examinerade vi de första fyra mästarna. Inte bara studenterna utvecklas, även själva programmet förändras över tid och trimmas in allt mer för att bli så tydligt och nyttigt som möjligt. Både för Omegapoint och studenterna.

Några av de nu examinerade studenterna hade redan under själva programmet börjat uppdrag i de roller de hade som mål och resultaten i övrigt var i vissa fall överväldigande. Så mycket som åstadkommits och så många givande diskussioner under resans gång. För att inte tala om alla bidrag till Academy i form av kompetensutveckling av kollegor genom kompetensdagspass, kursledning, bokcirklar, mentorskap mm.

Årets kull består av:

Emelie Ohlson med handledarna Rehanna Gerleman och Mats Persson
Mål: Compliance as Code

Victoria Catalán med handledaren Markus Örebrand
Mål: Från feature fokus till fokuserade team

Både Emelie och Victoria har mycket intressanta och högaktuella mål och jag ser fram emot att få följa deras utveckling och ta del av deras insikter under programmets gång. Ni kommer att få höra mer om deras arbete i kommande bloggposter där de själva får beskriva vad de vill göra och varför.

Stay tuned …

AMP med fokus på mognadsbedömningar

Innan jag började på Omegapoint så frilansade jag som egen konsult parallellt med studier på KTH. Som egen junior konsult var det svårt att hitta uppdrag jag tyckte var intressanta och jag tyckte också att jag saknade en större gemenskap. Jag hittade Omegapoint och deras kompetenskultur genom att jag var med på studentkonferensen och började min karriär och kompetensresa på Omegapoint för 3 år sedan, då som deltagare i Academy Professional Program.

Under mina tre år på Omegapoint har jag varit hos två kunder under längre perioder men också fått möjligheten att delta på en rad Technical Due Diligence av olika bolag. Under en Technical Due Diligence analyserar man ett bolags mognadsnivå i en rad olika områden, ofta på uppdrag av en investerare. Jag tyckte sådana bedömningar var väldigt roliga att genomföra, man får under en intensiv period inblick i hur ett bolag ser på utvecklingen av sin produkt, vilka bekymmer de har och hur de tacklar just sin branschs utmaningar. Det fick mig också att tänka på hur vi sprider kunskapen om att göra sådana bedömningar, hur vi vidareutvecklar vår produkt och att vi borde göra sådana mognadsbedömningar på våra befintliga kunder och våra egna team.

Dessa frågor fick mig att söka till Academy Masters Program (AMP) och påbörja mitt andra stora kompetensskutt på Omegapoint!

Mina mål med AMP

• Att själv bli expert på tekniska mognadsbedömningar

• Att ta leadroller ute hos kund och att kunna hjälpa kunden att förbättra sin organisations förmåga att leverera mjukvara snabbt och säkert

• Att bidra till kvaliteten och täckningen av Omegapoints tekniska bedömningar

• Att bidra till kunskapsspridningen inom Omegapoint inom området

Hur jag försöker uppnå målen

Det finns redan en uppsjö best practices och modeller för mognadsbedömningar av alla de slag. Jag började min resa genom att studera exempelvis OWASP OpenSAMM och utfallen från DORA State of DevOps. En observation som jag gjorde då var att det var blandad abstraktionsnivå på modellerna, en del är så abstrakta att det är svårt att förstå vad de egentligen menar, andra så specifika att de riskerar vara utdaterade innan mina 18 månader i AMP är över. Dessutom låg tonvikt på väldigt olika områden, State of Devops fokuserar på devops och kulturen kring det området, OpenSAMM fokuserar på säkerhet. Vissa modeller tog inte någon hänsyn alls till vart subjektet i fråga befann sig i för fas eller bransch. Ytterligare en aspekt jag tyckte jag behövde väva in är vad de som redan jobbade på Omegapoint som experter i exempelvis säkerhetsområdet tyckte.

Min hypotes blev att det är bättre att vi utvecklar vår egna modell som passar väl in i ramen hur vi vill utföra just den här typen av bedömningar. Modellen lånar friskt från andra modeller och våra egna experters erfarenheter. Den består av ett gäng olika capabilities vi tycker ett bolag bör ha, förklaring om vad vi menar i detalj, vanliga misstag man gör, när just denna capabilityn inte är applicerbar och ett gäng frågor för att stötta under intervjuprocessen. Planen är att successivt provköra modellen och iterera fram något vi blir nöjda med. Men jag tror det blir lättast att förklara med ett litet exempel hur en intervju går till, där intervjufrågorna och våra rekommendationer baserar sig på modellen:

Startupen ACME AB förmedlar en B2B tjänst där företag snabbt kan beställa in närmsta tillgängliga reparatör för att fylla på och laga kaffemaskiner. ACME AB är live och har nu ett hundratal kunder och fyra leverantörer av reparationstjänster. Bolaget består av fyra anställda, CEO som sköter ekonomi och marknadsföring, CTO Ragnar som dessutom är utvecklare och skrivit det mesta av kodbasen, en webutvecklare och en testare. Vi har bara fått en dag för bedömningen och intervjuar här Ragnar om testdata:

A: “Hur hanterar ni er testdata?”

R: “Ja du, bra tycker jag. Vi har ett skript som drar ned den, tvättar bort kunddatan och så trycker vi in datan i testmiljön”

A: “Okej, går det att köra testen lokalt också?”

R: “Ja, det är bara att man kör skriptet på sin utvecklingsmaskin. Alla utvecklare kör skriptet, vi behöver ju datan för att kunna testa”

A: “Hur mycket data snackar vi om?”

R: “Ungefär 1 TB, alltså, det inkluderar ju all data om användarbeteende som vi samlar in i webportalen, det är därför det blir så mycket”

A: “Okej, använder ni den datan till något? Beror några tester på den?”

R: “Nja, inte än, men vi har stora planer att bli en data driven dynamisk tjänst, ser vi att användaren darrar med musen exempelvis, vill vi framhäva nödknappen för att beställa en kaffemaskinsreparatör”

A: “Berätta mer om hur ni anonymiserar datan…”

Det kan ta tid att utreda alla aspekter av hur ACME AB hanterar sin test data, så vi nöjer oss här och fokuserar mer på vad vi skulle ge för feedback. I realtiteten skulle man borra ned sig djupare i vissa områden och även ta en titt på skriptet Ragnar pratat om.

• ACME AB verkar bero lite väl mycket på extern data för sina tester. Ett vanligt misstag är att låta även unit tester bero på externt state som i detta fall, produktionsdata. Vi rekommenderar ACME AB att i betydligt högre grad mocka externa beroenden och att sätta upp testdatan i testerna i kod, så den blir versionerad tillsammans med testet. Vi anser detta bör göras omgående då ACME är en startup och sannolikt kommer ändra sitt dataschema mycket den närmsta tiden, det gör att risken ökar för att mycket tid och pengar måste läggas på att laga trasiga tester.

• ACME AB hämtar också ut alldeles för mycket data. 1 TB tar en stund att ladda ned och detta leder till både frustration för utvecklarna och att utvecklingshastigheten minskar. Mer specifikt påverkar detta hur lång tid det tar för en förändring att komma till produktion. I de fall ni måste bero på produktionsdata i tester bör det endast vara precis den data som är intressant för testerna. Vi anser att detta är något som borde åtgärdas omgående då det direkt påverkar värdet era utvecklare kan producera.

• Vad gäller anonymisering av data…

För att återkoppla lite till målen så tror jag att även om vi finner att det var en mindre fantastisk idé att försöka utveckla en egen modell, så kommer jag själv komma en bra bit på väg mot att bli expert genom modellens utvecklande. Jag kommer också få praktiskt erfarenhet genom att genomföra ännu fler bedömningar där jag driver bedömningarna själv i högre grad, vilket kommer hjälpa mot målet att ta mer lead ute på uppdrag. Då jag kontinuerligt har interna workshops i området så bidrar jag till vår interna kunskapsspridning. Visar sig modellen dessutom fungera bra så tror jag att det går att göra Omegapoints tekniska bedömningar ännu ett snäpp vassare.

AMP med fokus på frontend

Mitt namn är Maryam Alizadeh och jag har arbetat på Omegapoint sedan våren 2018. Under januari 2021 påbörjade jag Omegapoints AMP ( Academy Masters Program ) med fokus på frontend.

Jag har arbetat som både backend -och frontend-utvecklare och det har fått mig att inse att det är frontend som jag vill bemästra och spetsa mig inom. Mitt mål är att en dag kunna ta rollen som Tech Lead inom webb. Då dom flesta Tech Leads som jag har stött på har många års erfarenhet, något som jag i skrivande stund ännu saknar, så började jag fundera: “kan jag accelerera processen”? Och det var därför jag sökte mig till AMP, det var och är mitt sätt att snabbare få min karriär dit jag vill.

Mina mål med AMP

Det första jag gjorde var att sätta upp egenskaper och mål för mig att fokusera på och se till att ha med dem i alla delmoment under programmets gång. Det jag valde att lägga fokus på till att börja med är;

• Känna trygghet i att kunna välja teknikstack åt ett mindre eller medelstort företags webbplats/webblösning

• Fördjupa mina frontend-kunskaper i bland annat prestanda och digital tillgänglighet

• Kunna leda och ta ansvar för ett team/en leverans.

Att mäta min progress

Redan från start märkte jag att det skulle vara svårt för mig att kunna verifiera min progress, jag hittade exempelvis inga certifikat som kunde hjälpa mig validera min kompetensnivå. Då fick jag specificera vad som skulle behövas för att kunna understryka min kompetens inom ämnet och prioritera om mina fokusområden, sedan försöka hitta andra sätta att mäta min utveckling. Det gjorde jag genom att ställa specifika frågor till mig själv;

• Vad behöver jag för färdigheter inom det här området?

• Hur kan jag testa min kunnighet inom området?

Mål: Trygghet i att välja teknikstack

Att kunna veta vilket teknikval som är bäst lämpad till en specifik produkt eller tjänst är något jag tycker är en av nyckelegenskaperna för en Tech Lead. Denna förmåga tänkte jag uppnå genom att få in följande i min vardagsrutin;

• Hålla mig uppdaterad med det senaste inom frontend

• Delta i kurser som är relevanta för mina områden

• Labba med olika tekniker, ramverk och bibliotek

Mål: Förbättra mina frontend-kunskaper

Detta mål går väldigt mycket ihop med förgående, eftersom när jag går kurser och testar olika tekniker både breddar och fördjupar mina frontend-kunskaper. 

Mål: Leda och ta ansvar för ett team/en leverans

Det här målet är svårast att hitta aktiviteter för som täcker mer än det man kan lära sig i teorin. Jag tycker att det krävs mycket praktiskt arbete för att kunna bli en bra ledare. Man kan utbilda sig till viss del, men man måste också prova sig fram, eftersom gruppdynamiken i ett team behöver inte nödvändigtvis vara likt ett annat. Jag planerar att gå de kurser som jag ser som relevanta, men också delta i Omegapoints interna projekt där jag får möjligheten att öva på dessa färdigheter. Ett exempel är Omegapoints initiativ för att öka mångfald i branschen där jag är mentor åt en student.

Mervärde för Omegapoint

Inom AMP fokuserar vi inte bara på egen utveckling, utan vi ska också sprida vår nyförvärvade kunskap till övriga anställda i bolaget. Jag har tänkt att under programmets gång hålla presentationer om de ämnen jag lär mig om, samt påbörja utformningen av en plan för uppföljningskurs till vår Webbutveckling 101.

Avslutning

Mitt fokus just nu är att utforska hur jag kan optimera prestanda på en sida. Dels hur man kan snabba upp den initiala laddningstiden, dels hur tillgänglighet bidrar till att öka prestanda för slutanvändare. 

Academy Master Program Cloud Security

Mitt namn är Alexander och jag är en av de tre som går AMP för år 2021. Academy Master Program, eller AMP, är ett program på Omegapoint som fokuserar på att ge anställda med två till fem års erfarenhet en skjuts i karriären. Programmet utformas av personen som går det tillsammans med en mentor som är expert inom ämnet. Programmet pågår i 18 månader och är på 20%, alltså ca 8 timmar per vecka. Vi som går AMP har lite olika inriktningar men mitt program är inriktat på moln och säkerhet där slutmålet är att bli tech lead. Jag trillade in på att jobba med moln 2019 och jobbade då egentligen på en AI avdelning men hamnade av en slump på ett AWS projekt istället. Efter det projektet började jag med AI igen men insåg snabbt att det var moln jag ville hålla på med. När jag fick reda på vad AMP var så fanns det inga tvivel, jag visste direkt att jag ville vara en del av det.

Mål

Främst så har jag planerat in fyra certifieringar

• AZ-303

• AZ-500

• AWS Solutions Architect Professional

• AWS Security Speciality

Eftersom jag redan har AWS Solutions Architect Associate så är den inte med i min lista men för dig som inte har den så skulle jag rekommendera att ta den innan.
Certifieringarna är mål och inte nödvändigtvis en del av examen, utbildningen kan alltså ändras med tiden. Det är också inplanerat en del saker utöver certifieringarna, så som att ta fram en kurs och att läsa relevanta böcker. Jag är även mentor för en kollega som går vårat trainee program, Academy Professional Program.

Innan jag ansökte till AMP så visste jag att jag behövde bli bättre på säkerhet och hade funderat ett tag på hur jag skulle gå tillväga för att få den kompetensen. Jag tyckte därför att det var väldigt svårt att definera vad jag ville få ut av AMP men tack vare min mentor och våra experter på Omegapoint så är det nu tydligt. Kunskapsglappet som jag har upplevt har nu blivit mer definerat och därmed känns det lättare att jobba mot att få den kompetensen som behövs.

Nu

Just nu jobbar jag mot att ta AZ-303 certifieringen och börjar närma mig att kunna ta slutprovet. Jag har valt att jobba mot både Azure och AWS för att få en bredare kompetens och jag tror att det ligger en rejäl styrka i att kunna jämföra molnleverantörernas mot varandra för våra kunders skull. Till en början så har jag valt att fokusera på Azure, det valet beror på att jag för närvarande sitter i ett projekt som byggs i Azure.

Projektet jag jobbar med nu går ut på att integrera ett tiotal organisationers betalsystem, vi hanterar alltså datan från betalningar som sker via organisationerna. Redan nu, tre månader in, så kan jag säga att valet att gå AMP har gett resultat och att jag kan bidra till mitt nuvarande projekt med markant skillnad från innan. Delvis så är det såklart på grund av att jag lär mig mycket under vanlig arbetstid men det är tydligt att mycket kommer från AMP.

Om du som läser det här är anställd på Omegapoint och är intresserad av att själv gå AMP så brukar ansökningen öppna runt hösten/vintern så det kan vara klokt att redan nu fundera ut vad du vill göra. Jag är mycket nöjd med att gå AMP och skulle rekommendera alla som har chansen att söka det, så om du vill höra mer om vad vi gör eller hur det fungerar så går det bra att höra av sig med frågor.

Kodgranskning, håll det enkelt och lättsmält

Det finns flera olika anledningar till att man använder sig av kodgranskningar i mjukvaruutveckling. Några vanliga exempel är p.g.a. säkerhetskrav, kvalitetskrav eller för att bidra till kunskapsspridning inom ett team.

Vanligvis kan en kodgranskning ske som ett mellansteg innan ändringar accepteras in i en kodbas, t.ex. innan en pull- eller merge-request accepteras.

Det är här som exempelvis andra medlemmar i ett team ska läsa och förstå ändringen för att sedan kunna ge feedback i form av ett godkännande eller nekande. Om ändringen inte går att förstå eller om något är felaktigt kan man självklart ställa frågor eller föreslå förändringar. Men varje extra steg gör också att hela processen tar mer tid och energi från deltagarna.

Drar man paralleller till metodiker inom agil utveckling så kan man kanske se kodgranskning som en feedback-loop som riskerar att bli väldigt långsam. Om det är möjligt kanske man vill minska loopen genom att synka med teamet ofta eller kanske rentutav par- eller mobbprogrammera tillsammans.

Skall man genomföra kodgranskningar bör ett viktigt mål vara att göra granskningen så pass tydlig och enkel som möjligt.

Vid en granskning behöver en granskare åtminstone ta ställning till följande:

• Förståelse (Går det att förstå vad ändringen gör?)

• Korrekthet (Är denna ändring korrekt utifrån problembeskrivingen?)

Båda dessa punkter blir svårare och svårare ju mer komplicerad ändringen är. Håll därför ned komplexiteten på det enklast möjliga sättet: Genom att bryta ner ändringarna i mindre bitar.

Att bryta ner ändringarna i mindre och mer hanterbara delar är inget nytt. Denna förmåga är välgrundad inom DevOps-sfären och empiriskt bevisad att den bidrar till en högre utvecklingstakt. Läs mer

Så, gör det tydligt vad en granskare bör fokusera på i en kodändring.
Håll det enkelt och lättsmält.

Tips: Håll ändringar separata

En vanlig anledning till att kodändringar kan vara svåra att förstå är att man gör flera ändringar samtidigt. Även om ändringarna är helt funktionellt separata så måste man som granskare ta till sig och förstå om de olika delarna av koden faktiskt påverkar varandra. Om ändringarna inte påverkar varandra, gör det då tydligt genom att granska dem separat.

Tips: Försök arbeta mot mindre och tydligare ändringar

Även om det leder till fler kodgranskningar så borde de sammanlagt ta mindre tid och samtidigt vara enklare att förstå och ta till sig.

DevOps-loopen och "Release on Demand"

DevOps-loopen

Om du skulle googla på "devops loop" skulle du förmodligen få mängder av träffar med varianter av följande bild:

Loopen försöker beskriva tanken med ett evigt kretslopp i utvecklingslivscykeln från planering till produktion via feedback tillbaka till planering och så vidare. Du kanske inte reflekterar över varje enskilt steg i loopen utan tänker att de beskrivna stegen och dess ordning verkar rimliga.

Jag som jobbar med att sprida budskapet kring säker utveckling och vikten av att lägga in aktiviteter kopplade till säkerhet i utvecklingslivscykeln har använt DevOps-loopen som ett pedagogiskt verktyg för att illustrera exempel på säkerhetsaktiviteter och dess plats i loopen:

• I “Plan” jobbar vi med C-I-A och Privacy-krav samt hotmodellering.

• I “Code” jobbar vi med pull-request/peer-review.

• I “Build” jobbar vi med statisk kodanalys (SAST) och skanning efter användning av sårbara externa komponenter (SCA) i vår build-pipeline.

• I “Test” jobbar vi med säkerhetsrelaterade tester, kanske skapade utifrån resultatet av en penetrationstest med ansatsen "hur kan vi säkerställa att detta inte händer igen".

Ni fattar tanken. Men när man kommer till “Release” och “Deploy” så blir det lite problematiskt. Kanske inte med att mappa aktiviteterna i sig men med frågeställningen, kommer verkligen “Release”-steget innan “Deploy” i en modern utvecklingslivscykel?

Release on demand

Av ren nyfikenhet på SAFe så gick jag en "Leading SAFe"-utbildning under våren och där pratade vi "Release on Demand" i avsnittet där man beskriver "Build a Continuous Delivery Pipeline with DevOps". Tanken är att du ska separera "deploy to production" från "release" så att värdet av det du gör görs tillgängligt när det behövs.

“Release on Demand - Making value available when it's needed”

I den DevOps-loop som används i deras material har man bytt plats på “Release”- och “Deploy”-stegen:

och då försvinner plötsligt problemet jag började med att beskriva kring ordningen på “Release”- och “Deploy”-stegen.

• I “Deploy” sätter vi ny funktionalitet i produktionsmiljön men den görs inte tillgänglig för kunden direkt utan nya funktioner kanske döljs bakom feature flags eller så använder vi canary-releases för att testa ny funktionalitet på en begränsad mängd användare till en början.

• I “Release” gör vi ny funktionalitet tillgänglig för alla kunder när det passar. Kanske direkt eller vid ett strategiskt valt tillfälle.

Den nya ordningen på stegen i DevOps-loopen känns helt rätt.

Så för att avsluta visar jag den alternativa (korrekta) versionen av DevOps-loopen med mina exempelaktiviteter kring säkerhet utmappade:

Den nya DevOps-loopen med exempel på säkerhetsaktiviteter i respektive steg

/Mats Persson - Säkerhetskonsult på Omegapoint, Mats LinkedIn-profil - 2020-09-08

Takeaways från AWS Summit Online

AWS brukar varje år arrangera flera endagars-konferenser runt om i värden, AWS Summits. I Stockholm brukar AWS Summit Stockholm arrangeras i maj. Sedan tidigt i våras har samtliga av dessa ställts in pga Covid-19. Istället bjöd AWS den 17 juni in till AWS Summit Online. En halvdags-konferens med 11(!) spår där samtliga föreläsningar finns tillgängliga i efterhand online. Svårighetsgraden på föreläsningarna varierade från introduction (Level 100) till expert (400) men med en tydlig tyngdpunkt på intermediate (200) och advanced (300). Efter att under ett par år ha varit på ett par AWS-events fysiskt och digitalt har jag lärt mig att lärt mig att med hjälp av titeln och nivå får man en väldigt bra överblick av om det är värt att gå på föreläsningen. Handlar den om ett område man inte är bekant med eller bara doppat tårna i kommer man inte att lära sig mycket från 300- eller 400-nivå. På samma sätt får man inte ut något av 100- eller ens 200-nivå om man är en van användare.

Överlag tyckte jag att konferensen höll bra kvalitet. Med 11 parallella spår är det mer troligt att man måste välja bort en eller flera intressanta föreläsningar än att man inte hittar något intressant att titta på. Jag försöker här sammanfatta ett par av de saker jag tar med mig från dagen. Jag försökte fokusera mina val mot säkerhet och/eller arkitektur där det passade och det är framförallt från det tidigare jag tar med mig mest. En del tjänster och funktioner används naturligt, men det finns en del som man behöver lägga ner lite arbete på men som i längden kan ge väldigt mycket tillbaka.

AWS har många tjänster inom säkerhetsövervakning och skydd: AWS Security Hub, Amazon GuardDuty och AWS Shield för att nämna några. Jag har varit vid flertalet föreläsningar där flera av dessa tjänster beskrivs och där jag kännt att det är väldigt bra verktyg att att jag/vi borde börja använda mer. Som utvecklare kanske det inte alla gånger är så naturligt att ta steget att börja experimentera med Amazon GuardDuty direkt. Det kanske är svårt att motivera varför tid ska läggas på detta. Jag tror att det finns en naturlig väg att komma in på automatiserad säkerhetsövervakning via loggning. De flesta om inte alla utvecklare i en DevOps-organisation kommer att stöta på incidenter där det har blivit något fel i någon av de tjänster man ansvarar för. Efter ett par liknande incidenter börjar utvecklaren troligen och även (förhoppningsvis) produktägaren att fundera på vad som kan göras för att minimera tiden som läggs på att hantera incidenter. Här kanske man nu bygger stödsystem för att förbättra och centralisera loggning. Man kanske automatiserar så att varje gång en viss typ av fel uppträder i loggarna så skickar man ett mail till utvecklaren. Nästa steg blir att man kan automatisera även vilket åtgärd man tar på felet. När man väl kommit så här långt är steget att bygga vidare. Nu kan vi med en lite större arbetsinsats utöver det stöd vi behöver för att lösa våra incidenter, även mitigera en säkerhetsrisk. Steget till att använda alla de säkerhetsverktyg som finns i AWS behöver inte vara så långt.

DevOoops!

Till vänster är den en grupp människor som kallas för ”dev”. Till höger är det en annan grupp människor som kallas för ”ops”. I mitten av bilden är det en hög mur. Har du också sett en sådan PowerPoint? I så fall har du också varit på en presentation om DevOps. Nyligen har jag haft några intressanta upplevelser i mitt projekt:

1. Jag pushar en ny modul. En kollega berättar vid fikat att hen såg en ny modul och installerade, konfigurerade och startade den i en testmiljö. Hen undrade bara vad den gjorde.

2. Jag modifierade en modul så att det blev mera kräsen rörande konfigurationen, som dessutom hade ändrats lite. Tyvärr så råkade System.exit(1) hamna före logger.fatal(”Incorrect configuration…”). Tjänsten avslutade utan att lämna minsta spår av vad som hade hänt.

Ooops! Gemensamt för dessa små incidenter är att vi gjorde en överlämning inom projektet. Jag och kollegan har bra kommunikation, ett lågt staket och inte en hög mur, och löste problemen på några minuter.

När jag har funderat mer på detta så har jag kommit fram till att låga staket - överlämningar inom ett projekt - är bra. Första fallet lär mig att all kod som jag pushar måste vara av så hög kvalitet att den går att installera utan att skada systemet. (Den behöver dock inte göra någon egentlig nytta.) I det andra fallet hade jag aldrig missat den förändrade konfigurationen om jag hade installerat själv och buggen hade aldrig hittats. Små överlämningar inom projektet höjer alltså kvaliteten på leveransen!

Att tillåta att DevOps ibland blir DevOoops! tror jag är ett effektivt och ekonomiskt fördelaktigt sätt att höja kvaliteten jämfört med både par-programmering och kod-granskning. Den lilla överlämningen inom teamet simulerar verkligheten på ett bra sätt och det kan vi dra nytta av.

Har du koll på dina antaganden?

Jag tänkte göra debut på denna blogg med ett ganska mjukt ämne. Jag blev tillfrågad att hålla en gästföreläsning på ett universitet och har väldigt fria händer att själv bestämma vad jag vill prata om. Det svåraste med den friheten är just att sätta gränser och bestämma vad jag ska bygga föreläsningen på. Som student minns jag ofta presentatörer från företag och de började alltid sin presentation med: ”Jag tänker nu dela med mig av något som jag insåg som nyexaminerad som jag aldrig fick från universitetet”.

Den utgångspunkten är ganska svår och kanske inte alltid får den slagkraft man vill. För i den utgångspunkten gör vi en del antaganden om publiken. Det som jag dels tänker på då är:

• Antagandet om att publiken någorlunda delar den bakgrund du hade som student. Har du något i din bakgrund som kanske påverkat det du såg? 

• Antagandet om att publiken läser och plockar upp ungefär samma saker som du gjorde i dina kurser. Delar vi någorlunda definitioner på det vi pratar om? 

• Antagandet om att studenten kommer att hamna på ett ställe som liknar det du hamnade i. Vad för faktorer i din miljö, roll eller problemområde kan ha påverkat din insikt?

För när vi försöker förmedla något man lärt oss genom en process i en viss miljö blir det svårt att värdera det någon säger om vi inte hjälper lyssnaren med transparens i de här delarna. Man kan absolut abstrahera insikter och problem till den grad att man kan få en generaliserbarhet. För att återkomma till en bättre formulering: ”Jag tänker dela med mig av mina viktigaste insikter och hur jag förvärvade dem – Där jag kommer försöka sätta saker i kontext där insikterna kan vara giltiga”