OpenAI has admitted a security breach at a third-party supplier exposed customer emails, location information, and “limited analytics data related to some users of the API”.

The supplier, Mixpanel, provides data analytics services via OpenAI’s developer platform. OpenAI said the platform is used to help “understand product usage” and improve services for its API product, platform.openai.com.

On 9 November, Mixpanel discovered an attacker gained unauthorized access to systems. They then exfiltrated a dataset containing “limited customer identifiable information and analytics information”.

A full outline of data exposed, per an OpenAI statement on the breach, includes:

• Names provided via Mixpanel API accounts
• Email addresses associated with the API account
• “Aproximate course location based on API user browsers” (including city, state, and country)
• Information on operating systems and browsers used to access the API account
• Referring websites associated with the API account

OpenAI has been keen to stress that the breach only affects developers and not general ChatGPT users. It also said developer credentials – including passwords, payment information, and government IDs – weren’t exposed.

OpenAI added that it’s currently in the process of notifying those affected by the incident.

A swift response from OpenAI

Upon discovery of the breach, OpenAI said it removed Mixpanel from production services and began a review of affected datasets.

While the investigation is still ongoing, the company noted it has so far found “no evidence of any effect on systems or data outside Mixpanel’s environment”.

The company has since terminated its use of the data analytics platform and said it will conduct a review of its broader supplier ecosystem.

“Trust, security, and privacy are foundational to our products, our organisation, and our mission, OpenAI said in a statement. “We also hold our partners and vendors accountable for the highest bar for security and privacy of their services.”

Jake Moore, global cybersecurity advisor at ESET, commended OpenAI for its “swift move” in alerting users and cutting ties with the supplier. Many organizations try to minimize security incidents and keep them “under the radar”, he said.

“Companies often fear the aftermath of an attack and presume it will be brand damaging,” Moore commented. “However, openness is now deemed far more important and speed is usually of the essence in making anyone affected aware of the situation.”

Developers warned to remain vigilant

OpenAI said information exposed in the breach could be used by hackers to carry out future attacks on users and encouraged them to “remain vigilant”.

These types of warnings are common in the wake of a data breach, according to Moore.

“Even though the exposed data was low-sensitivity, it could still be misused in the likes of social engineering techniques or via phishing attacks because attackers could combine the data such as name, email, even approximate location data to craft convincing fraudulent messages,” he explained.

“As within the wake of typical data compromises, those affected need to remain vigilant for suspicious emails or other strange communications.”

MORE FROM ITPRO

• Gartner says 40% of enterprises will experience ‘shadow AI’ breaches by 2030
• AI breaches aren’t just a scare story any more – they’re happening in real life
• Impact of Asahi cyber attack laid bare as company confirms 1.5 million customers exposed

LevelBlue has announced a new strategic partnership with cybersecurity vendor Akamai to provide new managed web application and API protection services.

The new Managed Web Application and API Protection (WAAP) service aims to deliver flexible web app and API protection to help organizations consolidate, simplify, and scale their security.

Powered by Akamai’s App & API Protector technology, the offering combines next-gen web application firewall (WAF), distributed-denial-of-service (DDoS) mitigation, bot protection, and foundational API security capabilities, backed by LevelBlue’s WAAP Operations team.

In an announcement, LevelBlue president, Sundhar Annamalai, said the service offers a solution to the complexity, silos, and rising costs of the modern web app and API security landscape.

“LevelBlue offers an alternative: proven services that consolidate and simplify protections with predictable investment,” he added. “By combining LevelBlue’s operational expertise with Akamai’s proven technology, organizations can stay ahead of evolving threats and create cyber resilience for critical digital capabilities.”

What the partnership means for customers

Available in two tiers, Essential and Advanced, LevelBlue Managed WAAP combines AI-driven threat detection with global threat intelligence to catch anomalies, adapt to new attack vectors, and stay ahead of threats.

Organizations also benefit from automatic app and API prioritization, automated policy management to drive efficiency and reduce false positives, as well as around-the-clock access to WAAP specialists for support, monitoring, and advisory assistance.

The release comes as businesses continue to ramp up their use of web apps and APIs as part of their digital-first strategies.

According to research from Enterprise Strategy Group, the average number of web apps per organization is expected to rise from 145 to over 200 in the next two years, while those with over half their apps using APIs will shoot up from 32% to 80%

This sharp increase in ecosystem complexity brings fresh security challenges, particularly around app and API deployments and scaling, compounded further by industry staff constraints and skills gaps.

Rupesh Chokshi, senior vice president and general manager of Akamai’s Application Security Portfolio, said the company saw more than 311 billion web app attacks in 2024 alone.

“As AI accelerates, threats are harder to spot, and security is tougher to control,” he explained.

“Akamai and LevelBlue’s partnership gives customers access to a trusted, reliable team that combines industry-leading technology with the deep operational expertise of one of the world’s largest MSSPs.

“It’s a powerful combination with a flexible solution that can fast-track organizations to resilient protection and compliance."

MORE FROM CHANNELPRO

• MSPs beware – these two ransomware groups are ramping up attacks
• SonicWall launches new firewalls as part of Generation 8 refresh
• Fortinet hits major milestone as partner program surpasses 400 partners

There are many things to do when starting a company. Find desk space, register the company, get a bank account, set up the website, and all the other tasks that require different hats to be worn. If the idiom were reality, hatters and milliners would be present at every startup accelerator. 

You quickly need a product or service to offer your customers. Without this, you won’t be in business for long, unless you already have other revenue streams or your investors or lenders are patient. Funnily enough, they never seem to be. 

You’ve probably already thought of an idea already; you think it’s going to change the world for the better, solve someone’s problem, or mitigate someone’s risk – possibly you hope it’ll do all three. So how are you going to get from A to B, where A is nothing but a headful of ideas, and B is a product in someone’s hand being used “in production”?  

We faced the same challenge when we started a company six years ago, armed only with a couple of laptops and a list of good contacts. You’ll need to work hard on networking throughout your journey – it’s hard to bring a product to life without a lot of help from others. 

Laying the groundwork

We wanted to disrupt existing practices in an area of healthcare research that aims to understand patient outcomes and experiences, outside of clinical trials, in almost any disease area. First, we needed to establish at least an outline “product-market fit”. We knew we had to ask ourselves – and answer – some very searching questions. These include: 

• Who are your customers?
• What problem(s) are you trying to solve for them?
• Do your customers even know what problem(s) they have?
• Will customers pay (and continue to pay) for that solution?
• What are they currently doing instead?
• If something already exists, how does it compare?
• How will you measure success?
• What does good look like?
• Are there any early KPIs/OKRs you can use to judge your progress?

We set out to validate our ideas by working with senior clinicians at The Royal Marsden Hospital in London, one of the world’s leading hospitals dedicated to cancer treatment and research. They helped us understand the contours of patient experience in oncology, many aspects of which extend across other disease areas too. We also ideated at length with industry experts at major pharmaceutical companies to gain insight into the types of evidential gaps they are trying to fill and where our solution could help with that.  

Finally, we checked the regulatory landscape to understand external constraints such as ethics, pharmacovigilance, data protection, and security requirements. Make sure you know who your key opinion leaders are and then ask as many questions as you can – most people are happy to have a chat over coffee, especially if you aim to improve the way things work in their industry. 

The building phase

With your assumptions challenged and your offer refined, you can move on to a highly creative and productive phase that will shape your product much further and quicker than you have so far. You need to start product iteration, which is a cycle of designing, testing, prototyping, and perfecting. Regular inspections and feedback are key to this process; as is listening. Remember the Lean methodology of “think big, act small, fail fast, learn quickly”. 

For this, we created the cheapest, quickest version of the product that we could and got feedback on it as early as possible. This way the cost of “failure” was very low, and we could easily pivot or simply remove functionality and try something new. You can find several ways to create minimally viable versions – wireframing tools help a lot here, but I’ve seen early product ideation done on paper.  

In our early user testing, we implemented clickable wireframes for mobile devices, which we chose as our initial target form factor. One version was a fully featured prototype that had the feel of a complete app but was built at a fraction of the cost. There are also now no-code or low-code solutions that go a stage further and provide basic functionality that further blurs the lines between prototype and minimum viable product (MVP). 

Asking for feedback

Who should you ask for feedback? It could be anyone: friends, family, and colleagues will all have useful thoughts. All feedback is a gift, and this is one that keeps giving. The best option is to ask your prospective end users.  

Don’t get too stuck on exactly who to ask. I guarantee the minute the rubber hits the road, you’ll start learning things you didn’t realize, or think were important yet. When we got feedback from people living with an autoimmune condition that caused muscle weakness, particularly in their eyelids, we soon realized it was hard for them to scan up and down a long screen of text or icons – we hadn’t expected that, but now it became obvious. 

We then organized phone calls, online surveys, and even in-person focus groups at venues in London, Paris, and Milan. There are many options where people can take part remotely, even remotely screen and voice-recording to get stream-of-consciousness feedback from users, but in-person testing is still important as the level of insight it provides is great.  

Choosing your priorities

When you have some feedback, organize it into areas of functionality; let’s call them “epics”, given we’re already considering an agile approach. At this point, you’ll be creating a backlog of product ideas. You can’t really expect your users to tell you which of them will provide the most value; it’s up to you to listen carefully. Find out what they’re doing now: can you imagine them switching from that to using your shiny, new application instead?  

As part of our discovery, we wanted to know if people track things about their disease already, such as medication, side effects, and treatments. If so, where do they already do that? We found quite a few people using spreadsheets to do this. If you give them your app, is there any friction in moving over to it – how likely is it to happen?  

You’re often not competing with the things you think you are, such as better features and functionality. Often you’re competing for people’s attention, the span of which is now frighteningly short. Dealing with patients suffering from acute or chronic diseases, we found users already have a lot going on in their lives and spend time managing their condition, treatments, and side effects – we usually couldn’t expect them to spend long using our app too. There are exceptions, such as a group we studied who needed regular blood transfusions which take the best part of a day in the hospital during which they had time to provide feedback. A different consideration here is hospitals are often places with restricted connectivity, which can limit the use of mobile devices. 

Finalizing your product roadmap

Finally, it’s time to review the backlog and the epics you identified. Try to arrange these into a product roadmap. There is much to cover in product management but this would be a good time to familiarise yourself with two key frameworks. 

First is the Kano Model, which helps us prioritize features on a product roadmap according to the degree to which they will satisfy users. I like this framework because it focuses on user delight while creating the biggest bang for your buck. It also explains why today’s “wow” feature soon becomes expected. 

The other model is the Design Council’s Double Diamond. This encourages you to take a two-stage approach in your thinking; initially divergent exploration, and then convergent focus. It does this across two areas called the problem space and the solution space. 

We’ve used this to great effect as a means of moderating conversations while planning our product roadmap. The idea is to prevent you or your stakeholders from jumping straight to the first solution they can think of. Taking the time to check if you really understand the nature of the problem and brainstorming for several competing solutions sounds like common sense but be prepared to explain the Double Diamond repeatedly on your journey to a successful product. 

As you can see, the process of designing, testing, prototyping, and perfecting is endless but you’ll recognize when you have something good enough.  

Our first oncology study app was quite basic, but we soon added more functionality. It’s also about removing features. Users had asked us for a feature that found people nearby with a similar stage of disease for support, but it wasn’t used as much as we had hoped. In the end, we withdrew it. Nothing in product management is an exact science and the data and feedback can only tell you so much. Don’t be precious about any of your ideas or assumptions as they will probably all be challenged at some point and your product will usually end up looking quite different when your journey from A arrives at B.

Despite Kubernetes adoption soaring in recent years, users are concerned security strategies haven’t kept pace. 

A significant minority (38%) feel security isn’t taken seriously enough, according to Red Hat’s latest State of Kubernetes report, or that investment in containerized operations is inadequate. This is a rise of 7% against the previous year. 

These concerns are affecting the implementation of cloud native technologies, with 67% reporting delaying deployments due to security issues. 

Kubernetes security pain points

Security pain points include tooling around signing and verification according to Jeffrey Sica, principal developer experience engineer at the Cloud Native Computing Foundation (CNCF). “If the solution to a problem is difficult to implement, developers will go out of their way to shift – or not even address – the problem,” he tells ITPro.

Policy is also an issue, not only in terms of enforcement but also definition. “Businesses need some examples or sane defaults to build off of, and it seems there’s somewhere of a gap there,” Sica says. 

More than half of Red Hat’s respondents worry about misconfiguration and vulnerabilities due to Kubernetes’ level of customization, while the focus on upgradeability also poses security risks in some people’s eyes. 

One of Kubernete’s guiding principles is backward compatibility and so a default configuration release will never break an existing deployment. This means teams must pay special attention to new security features that may be disabled by default, notes Sandy Carielli, a principal analyst at Forrester. 

She also points to the fact more organizations need to realize Kubernetes security goes far beyond the API itself. “Because Kubernetes security also extends into application security, container security, identity management, and zero trust, security professionals must have basic familiarity with all of them and be able to collaborate across the team,” she adds. 

“Kubernetes is a Venn diagram over security disciplines and organizations can’t confine their discussion of Kubernetes security to just the Kubernetes settings.”

“At its core, Kubernetes is simply an API that allows the scheduling of containers. In that sense, the attack surface is the API server, or the containers being scheduled by Kubernetes,” continues Sica, who says that as container run times and Kubernetes, itself and defaults, have become more hardened, the focus has moved to the supply chain.

Is there a Kubernetes security deficit?

To some, these issues point to a security deficit, but Sica disagrees, instead pointing out if you compare the Kubernetes security space from 2018 to now, it’s night and day. His view is that there’s never been more effort and focus on security within Kubernetes and the cloud native ecosystem, which is down to adoption and maturity. 

“Five years ago there was a proverbial gold rush to adopt Kubernetes because it was the pattern to follow in application development. People and organizations alike had to go through the growing pains of adopting what was at the time radically new technology.

“Now that there’s less of a scramble to learn about Kubernetes, there’s a greater focus on the stability of the codebase and creating secure defaults,” he explains. 

There are many examples of how the cloud native community is addressing security concerns. For example, the CNCF instigated a Kubernetes security audit. This raised concerns about network permissions and intra-component communications, which have been – or are in the process of being – resolved by the community. 

In terms of supply chain security, Sica mentions Chainguard has been working closely with the Open Source Security Foundation (Open SSF) in creating extensive tooling for the signing and verification of software artifacts. 

Another large focus in terms of security is extended Berkeley Packet Filter (eBPF). “Notably Sysdig's Falco project, which can use either a kernel module or eBPF probe to monitor/log any kernel-level calls that a container can make,” says Sica. “This is the next logical step in observing or preventing any privilege escalation or container escapes.” 

Strategies to boost Kubernetes security 

The majority of organizations with security concerns are taking steps to address them, and are seeking the services of a handful of vendors, which are focusing on some or all aspects of the security challenge.

“I don’t find that security is putting companies off going down this path, or from doing more in this area. They’re carrying on – but with a focus on having secure containers,” says Charlie Winckless, a senior director analyst at Gartner. 

Winckless recommends adopting a tool that validates the security not just of your containers, but your Kubernetes environment – and preferably a single tool that does both. 

He notes a growing number of vendors are moving into this area, with some companies including Sidero Labs and Tigera focusing specifically on container security, while ‘big picture’ cloud security posture management (CSPM) vendors such as Wiz, Aqua, Orca and Palo Alto Networks are adding container security features to their platforms.

“Some are very much focused on that bigger picture, while others are addressing those micro markets,” he says.

Beyond tapping into the market, organizations can take a number of steps internally to shore up their container security. Winckless’ top tip is to “automate, then automate, and automate some more”. “If you don’t,” he continues, “then trying to keep up with the dynamism of these environments is very difficult.”

He also recommends validating (and automating that validation) your setup in the same way you’d treat other cloud providers, and in some cases using a managed Kubernetes environment. 

“A lot of people are adopting EKS in Amazon, GKE in Google, AKS in Azure to have something where at least in my underlying Kubernetes environment, some of that security responsibility is delegated to a cloud provider.

“For the most part – exceptions include choices Microsoft made that led to the Azurescape vulnerability for example – we still see the large cloud providers able to a do a better job of it than you can.”

A good API strategy is a key foundation for your digital transformation, with APIs optimising customer experiences, creating dynamic, digital ecosystems, and building platform business models.

In this report you will learn how API Management is critical to driving digital business and how IBM compares with other vendors in the API Management landscape based on current offerings, strategy, and market presence scores.

Download the report now to learn:

• How each solution measures up and their inclusion criteria
• Strengths and weaknesses of top API management vendors
• The comprehensive set of evaluation criteria

Provided by  IBM